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版 本 控制 是 管理 数据 变更 的 艺术 ， 无 论 数据 变更 是 来 自 同一 个 人 ， 
还 是 来 自 不 同 的 人 一 个 团队 〉 。 版 本 控制 系统 不 但 要 忠实 地 记录 数据 
的 每 一 次 变更 ， 还 要 能 够 帮助 还 原 任何 一 次 历史 变更 ， 以 及 实现 团队 的 
协同 工作 等 。Git 就 是 版 本 控制 系统 中 的 佼佼 者 。 


我 对 版 本 控制 系统 的 兴趣 源 自 于 我 的 个 人 知识 管理 实践 ， 其 核心 就 
是 撰写 可 维护 的 文档 ， 并 保存 于 版 本 控制 系统 中 。 可 维护 文档 的 格式 可 
以 是 DocBook、FreeMind、reStructuredText 等 。 我 甚至 还 对 FreeMind 加 
以 改造 以 便 让 其 文档 格式 更 适合 于 版 本 控制 系统 ， 这 就 是 我 的 第 一 个 开 
源 实践 : 托管 于 SourceForge 上 的 FreeMind-MMX 项目 。 文 档 书 写 格式 
的 问题 解决 之 后 ， 就 是 文档 的 存储 问题 了 。 通 过 版 本 控制 系统 ， 很 自然 
地 就 可 以 实现 对 文档 历史 版 本 的 保存 ， 但 是 如 何 避 免 因为 版 本 控制 系统 
瘫痪 而 导致 数据 丢失 呢 ?Git 用 其 办 新 的 分 布 式 的 版 本 控制 设计 提供 了 
最 好 的 解决 方案 。 使 用 Git， 我 的 知识 库 不 再 只 有 唯一 的 版 本 库 与 之 对 
应 ， 而 是 可 以 通过 克隆 操作 分 发 到 不 同 的 磁盘 或 主机 上 ， 克 隆 的 版 本 库 
之 间 通 过 推送 (PUSH) 和 拉 回 (PULL ) 等 操作 进行 同步 ， 数 据 安 全 得 
到 了 极 大 的 提升 。 在 版 本 控制 系统 的 忠实 呵护 下 ， 我 的 知识 库 中 关于 
Git 的 FreeMind 脑 图 在 日 积 月 累 中 变 得 越 来 越 翔 实 ， 越 来 越 清晰 ， 最 终 
成 为 本 书 的 雏形 。 

















版 本 控制 能 决定 项 目的 成 败 ， 甚 至 是 公司 的 生死 ， 此 言 不 虚 。 我 在 
推广 开源 项 目 管理 工具 和 为 企业 提供 咨询 服务 的 过 程 中 看 到 ， 有 很 多 团 
队 因 为 版 本 控制 系统 管理 的 混乱 导致 项 目 延 期 、 修 正 的 Bug 重 现 、 客 户 
的 问题 不 能 在 代码 中 定位 .…… 无 论 他 们 使 用 的 是 什么 版 本 控制 系统 《〈 开 
源 的 或 是 商业 的 ) 都 是 如 此 。 这 是 因为 传统 的 集中 式 版 本 控制 系统 不 能 
有 效 地 管理 分 文 和 进行 分 支 间 合并 。 集 中 管理 的 版 本 库 只 有 唯一 的 分 支 
命名 空间 ， 需 要 专人 管理 ， 从 而 造成 分 文 创建 的 不 自由; 分支 间 的 合并 
要 么 因为 缺乏 追踪 导致 重复 合并 、 引 发 严重 冲突 ， 要 么 因为 版 本 控制 系 
统 本 号 整 脚 的 设计 导致 分 文 合 并 时 效率 低下 和 陷阱 重重 。Git 凭 借 其 灵 
活 的 设计 让 项 目 摆脱 分 支管 理 的 梦 麻 。 





我 的 公司 也 经 历 过 代码 管理 的 生死 考验 。 因 为 公司 的 开发 模式 主要 
是 基于 开源 软件 的 二 次 开发 ， 所 以 最 早 在 使 用 SVN 〈Subversion) 做 版 
本 控制 时 ， 很 自然 地 使 用 了 SVN 卖 主 分 支 模 型 来 管理 代码 。 随 着 增加 和 
修改 的 代码 越 来 越 多 ， 我 们 开发 的 软件 与 开源 软件 上 游 的 偏离 也 越 来 越 
远 ， 当 上 游 有 新 版 本 发 布 时 ， 最 早 可 能 只 用 几 个 小 时 就 可 以 将 改动 迁移 
过 去 ,但 是 如 果 对 上 游 的 改动 多 达 几 十 甚至 上 百 处 时 ， 迁 移 的 过 程 就 会 
异常 痛苦 ， 基 本 上 和 重新 做 一 遍 差 不 多 。 那 时 似乎 只 有 一 种 选择 : 不 再 
与 上 游 合 并 ， 不 再 追踪 上 游 的 改动 ， 而 这 与 公司 的 价值 观 “ 发 动 全 球 智 
慧 为 客户 创造 价值 ? 相 违背 。 迷 落 之 中 ， 分 布 式 版 本 控制 系统 球 然 而 
至 ， 原 来 版 本 控制 还 可 以 这 么 做 。 

















我 最 先 尝试 的 分 布 式 版 本 控制 系统 是 Hg (Mercurial〉， 当 发 现 Hg 
和 MQ (Hg 的 一 个 插件 〉 这 一 对 宝贝 儿 的 时 候 ， 我 如 获 至 宝 。 逐 渐 地 ， 
公司 的 版 本 库 都 迁移 到 了 Hg 上 。 但 随 着 新 的 开发 人 员 的 加 入 ， 问 题 义 
出 现 了 ， 一 个 人 使 用 Hg 和 MQ 很 好 ， 但 多 个 人 使 用 时 则 会 出 现 难 以 协同 
的 问题 。 于 是 我 们 大 胆 地 采用 了 Git， 并 在 实践 中 结合 Topgit 等 工具 进行 
代码 的 管理 。 再 一 次 ， 也 许 是 最 后 一 次 ， 我 们 的 代码 库 迁 移 到 了 Git。 

最 早 认 识 分 布 式 版 本 控制 ， 源 自 于 我 们 看 到 了 众多 开源 项 目的 版 本 


控制 系统 大 迁移 ， 这 场 迁 移 还 在 进行 中 。 


. MoinMoin 是 我 们 关注 的 一 个 开源 的 维基 软件 ，2006 年 ， 它 的 代码 
库 从 SVN 迁 移 到 了 Heg1|。 


Mailman 同 样 是 我 们 关注 的 一 个 开源 邮件 列表 软件 。2007 年 ， 它 
的 代码 库 从 SVN 迁 移 到 了 Bazaar 1 |。 


. Linux 采 用 Git 作 为 版 本 控制 系统 (一 点 都 不 奇怪 ， 因 为 Git 就 是 
Linus Torvalds 开 发 的 ) 。 


* Android 是 目前 最 为 流行 的 开源 项 目 之 一 ， 因 为 游 在 市 场 巨 大 ， 
已 经 吸引 了 越 来 越 多 的 开发 者 进入 这 个 市 场 ， 而 Android 就 是 用 Git 维 护 
的 。 








当 开 源 软 件 纷纷 倒 回 分 布 式 版 本 控制 系统 大 旗 (尤其 是 Git〉 的 时 


候 ， 很 多 商业 公司 也 在 行动 了 ， 尤 其 是 涉及 异地 团队 协同 和 Android 核 
心 代 码 定制 开发 的 公司 。 对 于 那些 因 保守 而 不 敢 同 Git 靠 拢 的 公司 ，Giit 
也 可 以 派 上 用 场 ， 因 为 Git 可 以 与 现在 大 多 数 公司 部 署 的 SVN 很 好 地 协 
同 ， 即 公司 的 服务 器 是 SVN， 开 及 者 的 客户 端 则 使 用 Git。 相 信和 随 着 Git 
的 普及 ， 以 及 公司 在 代码 管理 观念 上 的 改进 ， 会 有 更 多 的 公司 拥抱 
Git。 


本 书 的 组 织 





本 书 共 分 为 9 访 ， 前 8 篇 是 正文 ， 一 共 41 章 ， 第 9 篇 是 附录 。 


第 1 篇 讲解 了 Git 的 相关 概念 ， 以 及 安装 和 配置 的 方法 ， 共 3 章 。 第 1 
章 介绍 了 版 本 控制 的 历史 。 第 2 章 用 十 几 个 小 例子 介绍 了 Git 的 一 些 内 亮 
特性 ， 期 待 这 些 特性 能 够 让 你 爱 上 Git。 第 3 章 则 介绍 了 Git 在 三 种 主要 操 
作 系 统 平 台 上 的 安装 和 使 用 。 在 本 书 的 写作 过 程 中 ， 我 70% 的 时 间 使 用 
的 是 Debian Linux 操 作 系统 ，Linux 用 户 可 以 毫 无 障碍 地 完成 本 书 列举 的 
所 有 实践 操作 。 在 2010 年 年 底 ， 当 得 知 有 出 版 社 愿 意 出 版 这 本 书后 ， 我 
向 妻子 阿 巧 预 文 了 未 来 的 部 分 稿费 购买 了 我 的 第 一 台 MacBook Pro， 于 
是 本 书 就 有 了 较为 翔实 的 如 何在 Mac OS X 下 安装 和 使 用 Git 的 内 容 ， 以 
及 在 本 书 第 22 章 中 介绍 的 关于 Topgit 在 Mac OS X 上 的 部 署 和 改进 相关 的 
内 容 。 在 本 书 的 编辑 和 校对 过 程 中 因为 要 使 用 Word 格 式 的 文稿 ， 所 以 
本 书后 期 的 很 多 工作 是 在 运行 于 VirtualBox 下 的 Windows 虚 拟 机 中 完成 














的 ， 即 使 是 使 用 运行 于 资源 受 限 的 虚拟 机 中 的 Cygwin，Git 依 然 完美 地 
完成 了 工作 。 


第 2 篇 和 第 3 篇 详细 讲解 了 Git 的 使 用 方法 ， 是 本 书 的 基础 和 核心 ， 
大 约 占据 了 全 书 40% 的 篇 幅 。 这 两 骗 的 内 容 架 构 方 式 是 我 在 进行 SVN 培 
训 时 就 已 经 形成 的 习惯 ， 即 以 “独奏 ” 指 代 一 个 人 的 版 本 控制 所 要 讲述 的 
知识 点 ， 以 “和 声 ” 指 代 团 队 版 本 控制 涉及 的 话题 。 在 第 2 篇 “Git 独 
奏 ” 中 ， 本 书 将 Git 的 设计 原理 穿插 在 各 章 之 中 讲解 ， 因 为 唯 有 了 解 真相 
(Git 原 理 ) ， 才 有 可 能 自由 (掌握 Git〉。 在 第 3 篇 “Git 和 声 * 中 ， 本 书 
讲解 了 团队 版 本 控制 必须 掌握 的 里 程 碑 和 分 支 等 概念 ， 以 及 如 何 解 决 合 
并 中 遇 到 的 冲突 。 





第 4 篇 细致 地 讲解 了 Git 在 实际 工作 中 的 使 用 模式 。 除 了 传统 的 集中 
式 和 分 布 式 使 用 模式 之 外 ， 第 22 章 还 介绍 了 Topgit 在 定制 开发 中 的 应 
用 ， 这 也 是 我 公司 在 使 用 Git 时 采用 的 最 主要 的 模式 。 这 一 章 还 讲解 了 
我 对 Topgit 所 做 的 部 分 改进 ， 相 关 的 具体 介绍 最 早出 现在 我 公司 的 博客 
上 多 。 第 23~25 章 介绍 了 多 版 本 库 协 同 的 不 同方 法 ， 其 中 第 25 章 介绍 的 
一 个 独辟蹊径 的 解决 方案 是 由 Android 项 目 引 入 的 名 为 repo 的 工具 实现 
的 ， 我 对 其 进行 改造 后 可 以 让 这 个 工具 脱离 Gerrit 代 码 审核 服务 器 ， 直 
接 操作 Git 服 务 器 。 第 26 章 介绍 了 git-svn 这 一 工具 ， 该 工具 不 但 可 以 实现 
从 SVN 版 本 库 到 Git 版 本 库 的 迁移 ， 还 可 以 实现 以 Git 作 为 客户 端 向 SVN 


提交 。 


第 5 篇 介绍 了 Git 服 务 器 的 架设 。 本 篇 是 全 书 最 早 开始 撰写 的 部 分 ， 
这 是 因为 我 给 客户 做 的 Git 培 训 讲义 的 相关 内 容 不 够 详细 ， 于 是 应 客户 
要 求 针对 Gitolite 等 服务 器 的 架设 撰写 了 详细 的 管理 员 手 册 ， 即 本 书 的 第 
30 章 。 第 32 章 介绍 了 Android 项 目 在 Git 管 理 上 的 又 一 大 创造 ， 即 Gerrit， 
它 实 现 了 一 个 独特 的 集中 式 Git 版 本 库 管 理 模型 。 





第 6 篇 讲解 了 Git 版 本 库 的 迁移 。 其 中 第 34 章 详细 介绍 了 从 CVS 版 本 
库 到 Git 版 本 库 的 迁移 ， 其 迁移 过 程 也 可 以 作为 从 CVS 到 SVN 迁 移 的 借 
鉴 。 本 篇 还 介绍 了 从 SVN 和 Hg 版 本 库 到 Git 的 迁移 。 对 于 其 他 类 型 的 版 
本 库 ， 介 绍 了 一 个 通用 的 需要 编程 来 实现 的 方法 。 在 本 篇 的 最 后 还 介绍 
了 一 个 Git 版 本 库 整 理 的 利器 ， 可 以 理解 为 一 个 Git 库 转换 为 男 外 一 个 Git 
库 的 方法 。 





第 7 篇 是 关于 Git 的 其 他 应 用 ， 其 主要 内 容 介 绍 了 我 在 etckeeper 启 发 


下 开发 的 一 款 备 份 工具 Gistore， 该 工具 可 以 运行 于 Linux 和 Mac OS X 





第 8 篇 是 Git 杂 谈 。 其 中 第 40 章 的 内 容 可 供 路 平台 的 项 目 组 借鉴 。 第 
介 


41 章 介绍 了 一 些 在 前 面 没 有 涉及 的 Git 的 相关 功能 和 特性 。 


第 9 篇 是 附录 。 首 先 介 绍 了 完整 的 Git 命 令 索 引 ， 然 后 分 别 介绍 了 
CVS、SVN、Hg 与 Git 之 间 的 比较 和 命令 对 照 ， 对 于 有 其 他 版 本 控制 系 
统 使 用 经 验 的 用 户 而 言 ， 这 一 部 分 内 容 颇 具 参 考 价值 。 





适用 读者 


本 书 适合 所 有 翻 开 它 的 人 ， 因 为 我 知道 这 本 书 在 书店 里 一 定 是 放 在 
计算 机 图 书 专柜 。 本 书 尤 其 适合 以 下 几 类 读者 阅读 。 


1. 被 数据 同步 困扰 的 “电脑 人 人” 


困扰 “电脑 人 ”的 一 个 第 见 问题 是 ， 有 太 多 的 数据 需要 长 人 保存 ， 有 
太 多 的 电脑 设备 需要 数据 同步 。 可 能 有 的 人 会 说 :“ 像 Dropbox 一 样 的 网 
盘 可 以 帮助 我 呀 ”。 是 的 ， 云 存储 就 是 在 技术 逐渐 成 熟 之 后 应 运 而 生 的 
产品 ， 但 是 依然 解决 不 了 如 下 几 个 问题 : 多 个 设备 上 同时 修改 造成 的 冲 
突 ; 元 余数 据 传 输 造 成 的 带宽 瓶颈 ， 没 有 实现 真正 的 、 完 全 的 历史 变更 
数据 备份 。 有 具体 请 参见 本 书 第 7 篇 第 39 章 的 内 容 。 

















Git 可 以 在 数据 同步 方面 做 得 更 好 ， 甚 全 只 需 借 助 小 小 的 U 盘 就 可 以 
实现 多 人 电脑 的 数据 同步 ， 并 且 文 持 上 自动 的 冲突 解决 。 只 要 阅读 本 书 第 
1 篇 和 第 2 篇 ， 就 能 轻易 掌握 相关 的 操作 ， 实 现 数据 的 版 本 控制 和 同步 。 


2. 学 习 计 算 机 诬 程 的 学 生 








我 非常 后 悔 没 有 在 学 习 编 程 的 第 一 天 就 开始 使 用 版 本 控制 ， 在 学 校 
时 写 的 很 多 小 程序 和 函数 库 都 丢失 了 。 直 到 使 用 了 CVS 和 SVN 对 个 人 数 
据 进行 版 本 控制 之 后 ， 才 开始 把 每 一 天 的 变更 历史 都 保留 了 下 来 。Git 
在 这 方面 可 以 比 CVS 和 SVN 等 做 得 更 好 。 


在 阅读 完 本 书 的 前 3 篇 掌握 了 Git 的 基础 知识 之 后 ， 可 以 阅读 第 5 篇 
第 33 章 的 内 容 ， 通 过 Github 或 类 似 的 服务 提供 商 建 立 上 自己 的 版 本 库 托 
管 ， 为 自己 的 数据 找 一 个 安全 的 家 。 


3. 程 序 员 


使 用 Git 会 让 程序 员 有 更 多 的 时 间 体 轧 ， 因 为 可 以 更 快 地 完成 工 
作 。 分 布 式 版 本 控制 让 每 一 个 程序 员 都 能 在 本 地 拥有 一 个 完整 的 版 本 
库 ， 所 以 几乎 所 有 操作 都 能 够 脱离 网 络 执行 而 不 受 融 宽 的 限制 。 加 之 使 
用 了 智能 协议 ， 版 本 库 间 的 同步 不 但 减少 了 数据 传输 量 ， 还 能 显示 完成 
进度 。 














Git 帮 助 程 序 员 打开 了 进入 开源 世界 的 大 门 ， 进 而 开阔 视野 ， 提 升 
水 平 ， 增 加 择业 的 砖 码 。 看 看 使 用 Git 作 为 版 本 控制 的 开源 软件 吧 : 
Linux kernel、Android、Debian、Fedora、GNOME、KDevelop、 
jQuery、Prototype、PostgreSQL、Ruby on Rails...... 不 胜 枚 举 。 还 有 ， 
不 要 忘 了 所 有 的 SVN 版 本 库 都 可 以 通过 Git 方 式 更 好 地 访问 。 


作为 一 个 程序 员 ， 必 须 有 具备 团队 协同 能 力 ， 本 书 第 3 篇 应 该 作为 学 
习 的 重点 。 


4.Android 程 序 员 





如 果 你 是 谷歌 Android 项 目的 参与 者 ， 尤 其 是 驱动 开发 和 核心 开 友 


的 参与 者 ， 必 然 会 接触 Git、repo 和 Gerrit。 对 于 只 是 偶尔 参考 一 下 
Android 核 心 代码 的 Android 应 用 开发 人 员 而 言 ， 也 需要 对 repo 有 深入 的 
理解 ， 这 样 才 不 至 于 每 次 为 同步 代码 而 耗费 一 天 的 时 间 。 


repo 是 Android 为 了 解决 Git 多 版 本 库 管 理 问 题 而 设计 的 工具 ， 在 本 


书 第 4 篇 第 25 章 有 详细 介绍 。 








Gerrit 是 谷歌 为 了 避免 因 分 布 式 开发 造成 项 目 分 裂 而 开发 的 工具 ， 
打造 了 Android 独 具 一 格 的 集中 式 管理 模式 ， 在 本 书 第 5 篇 第 32 章 有 详细 


站 绍 。 





> 





即使 是 非 Android 项 目 ， 也 可 以 使 用 这 两 款 工具 为 自己 的 项 目 服 
务 。 我 还 为 repo 写 了 几 个 新 的 子 命 令 以 实现 脱离 Gerrit 提 交 ， 让 repo 拥 有 
更 广泛 的 应 用 领域 。 


5. 定 制 开 发 程序 员 





当 一 个 公司 的 软件 产品 需要 针对 不 同 的 用 户 进行 定制 开发 时 ， 就 需 
要 在 一 个 版 本 库 中 建立 大 量 的 特性 分 文 ， 使 用 SVN 的 分 支管 理 远 不 如 使 
用 Git 的 分 支管 理 那 么 自然 和 方便 。 还 有 一 个 应 用 领域 就 是 对 第 三 方 代 
码 进行 维护 。 当 使 用 SVN 进 行 版 本 控制 时 ， 最 自然 的 选择 是 卖主 分 支 ， 
但 随 独 定制 开发 的 逐渐 深入 ， 与 上 游 的 侦 离 也 会 越 大 ， 于 是 与 上 洲 代 码 
的 合并 也 将 越 来 越 令 人 痛 舌 。 

















第 4 篇 第 22 章 介绍 Topgit 这 一 杀手 级 的 工具 ， 这 是 这 个 领域 最 佳 的 解 


决 方案 。 


6.SVN 用 户 





商业 软件 的 研发 团队 因为 需要 精细 的 代码 授权 ， 所 以 不 会 轻易 更 换 
现 有 的 SVN 版 本 控制 系统 ， 这 种 情况 下 Git 依 然 大 有 作为 。 无 论 是 出 差 
在 外 ， 或 是 在 家 办 公 ， 或 是 开发 团队 分 处 异地 ， 都 会 遇 到 SVN 版 本 控制 
服务 器 无 法 访问 或 速度 较 慢 的 情况 。 这 时 git-svn 这 一 工具 会 将 Git 和 SVN 
完美 地 结合 在 一 起 ， 既 严格 遵守 SVN 的 授权 规定 ， 又 可 以 自如 地 进行 本 
地 提交 ， 当 能 够 连接 到 SVN 服 务 器 时 ， 可 以 在 悠闲 地 喝 着 绿茶 的 同时 ， 
等 待 一 次 性 批量 提交 的 完成 。 











我 有 几 个 项 目 (pySvnManager、Freemind-MMX) 托管 在 
SourceForge 的 SVN 服 务 器 上 ， 现 在 都 是 先 通过 git-svn 将 其 转化 为 本 地 的 
Git 库 ， 然 后 再 使 用 的 。 以 这 样 的 方式 访问 历史 数据 、 比 较 代 码 或 提交 
代码 ， 再 也 不 会 因为 网 速 太 慢 而 望 眼 欲 穿 了 。 














本 书 第 4 篇 第 26 章 详细 介绍 了 Git 和 SVN 的 互 操作 。 


Git 在 很 大 程度 上 减轻 了 管理 员 的 负担 : 分 文 的 创建 和 删除 不 再 需 
要 管理 员 统一 管理 ， 因 为 作为 分 布 式 版 本 控制 系统 ， 每 一 个 死 隆 惑 是 一 








个 分 文 ， 每 一 个 克隆 部 拥有 独立 的 分 支 命 名 空间 ; 管理 员 也 不 再 需要 为 
版 本 库 的 备份 操心 ， 因 为 每 一 个 项 目 成 员 都 拥有 一 个 备份 ， 管 理 员 也 不 
必 担 心 有 人 在 服务 需 上 自 改 版 本 库 ， 因 为 Git 版 本 库 的 每 一 个 对 象 〈 提 
交 和 文件 等 ) 都 使 用 SHA1 哈 希 值 进行 完整 性 校 验 ， 任 何 对 历史 数据 的 
自 改 都 会 因为 对 后 续 提 交 产 生 的 连锁 反应 而 原形 毕露 。 











本 书 第 7 篇 第 37 半 介绍 了 一 丈 我 开发 的 基于 Git 的 备份 工具 ， 它 使 得 
Linux 系 统 的 数据 备份 易如反掌 。 本 书 第 5 篇 介绍 的 Git 服 务 如 搭 建 ， 以 及 
第 6 篇 介绍 的 版 本 库 迁 移 方面 的 知识 会 为 版 本 控制 管理 员 的 日 常 维护 工 
作 提 供 指引 。 





8. 开 发 经 理 


作为 开发 经 理 ， 你 一 定 要 对 代码 分 文 有 深刻 的 理解 ， 不 知 本 书 第 18 
章 中 的 “代码 管理 之 殉 " 是 否 能 引起 你 的 共鸣 。 为 了 能 在 各 种 情况 下 恰当 
地 管理 开发 团队 ， 第 4 篇 “Git 协 同 模型 ”是 项 目 经 理应 该 关注 的 重点 。 你 
的 团队 是 否 存在 着 跨 平台 开发 ， 或 者 潜在 着 跨 平台 开发 的 可 能 ?本 书 第 
8 篇 第 40 章 也 是 开发 经 理应 当 关 注 的 内 容 。 








排版 约定 


本 书 使 用 的 排版 格式 约定 如 下 : 


1 命令 输出 及 示例 代码 


执行 一 条 Git 命 令 及 其 输出 的 示例 如 下 : 





$ git --version 
git version 1.7.4 





2. 提 示 符 ($) 


前 面 的 $ 符 号 代表 命令 提示 符 。 


如 


3. 等 宽 字 体 (Constant width) 


用 于 标示 屏幕 输出 的 字符 、 示 例 代 码 ， 以 及 正文 中 出 现 的 命令 、 参 
数 、 文 件 名 和 函数 名 等 。 


4. 等 宽 粗 体 (Constant width bold ) 
用 于 表示 由 用 户 手工 输入 的 内 容 。 
5. 占 位 符 (<Constant width>) 


用 尖 括 号 扩 起 来 的 内 容 ， 表 示 命 令 中 或 代码 中 的 占 位 符 ， 读 者 应 当 
用 实际 值 将 其 答 换 。 





“官方 网 站 : http://www.ossxp.com/doc/gotgit/ 











在 本 书 的 官方 网 站 上 ， 大 家 可 以 了 解 到 与 本 书 相 关 的 最 新 信息 ， 香 
看 本 书 的 勘误 ， 以 及 下 载 与 本 书 相 关 的 资源 。 官 网 是 以 Git 方 式 维护 
的 ， 人 人 都 可 以 参与 其 中 。 





.新浪 微 博 : http://weibo.com/GotGit 


欢迎 大 家 通过 新 浪 微 博 与 作者 交流 ， 也 欢迎 大 家 通过 新 浪 微 博 将 你 
们 的 宝贵 意见 和 建议 反馈 给 作者 。 
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辑 。 甚 至 没有 回 我 索要 样 章 ， 在 看 过 目录 之 后 就 < 骨 险 ”和 我 签约 ， 他 的 
激情 让 我 不 敢 懈 仿 。 同 样 要 感谢 王 晓 菲 编辑 ， 她 的 耐心 和 细致 让 我 吃 
惊 ， 也 正 是 因为 她 的 工作 本 书 的 行文 才能 更 加 流畅 ， 本 书 也 才能 够 更 快 











问世 。 还 有 张 少 波 编辑 ， 感 谢 她 在 接 到 我 的 电话 后 帮 我 分 析 选 题 并 推荐 
给 杨 福 川 编辑 。 


本 书 的 部 分 内 容 是 由 我 的 Git 培 训 讲 义 扩展 而 来 的 ， 在 此 感谢 朝 歌 
数码 的 蒋 宗 贵 ， 是 他 的 鼓励 和 纵 策 让 我 完善 了 本 书 中 的 与 服务 器 架设 的 
相关 章节 。 还 要 感谢 王 彦 宁 ， 正 是 通过 她 的 团队 我 才 认识 了 Android， 
才 有 了 本 书 关 于 repo 和 Gerrit 的 相关 章节 








感谢 群英 汇 的 同事 们 ， 尤 其 要 感谢 王 胜 ， 正 是 因为 我 们 在 使 用 
Topgit 0.7 版 本 时 遇 到 了 严重 的 冲突 ， 才 使 我 下 定 决 心 研究 Git。 











感谢 上 海 爱 立信 研发 中 心 的 高 级 技术 专家 蒙 爆 ， 他 对 全 书 尤 其 是 
gitrsvn 和 Gitolite 相 关 章 节 做 了 重点 评审 ， 他 的 意见 和 建议 修正 了 本 书 的 
很 多 不 当 之 处 。 因 为 时 间 的 关系 ， 他 的 一 些 非常 好 的 观点 没有 机 会 在 这 
一 版 中 体现 ， 争 取 在 改版 时 弥补 遗憾 。 





中 国 科 学 院 软 件 研究 所 的 张 先 轶 、 比 蒙 科 技 的 宋 伯 润 和 杨 致 伟 、 麻 
博 科 技 的 能 军 、 共 致 开源 的 秦 红 胜 ， 以 及 王 胜 等 人 为 本 书 的 技术 审 校 提 
供 了 帮助 ， 感 谢 他 们 的 宝贵 意见 和 建议 。 来 自 中 国 台 湾 的 PyLabs 团 队 纠 
正 了 本 书 在 对 Hg 的 认识 上 的 偏颇 ， 让 本 书 附 录 中 的 相关 内 容 更 加 准确 
和 客观 ， 在 此 向 他 们 表示 感谢 。 








因为 写 书 亏欠 家 人 很 多 ， 直 到 最 近 才 发 现 女 儿 小 雪 是 多 么 希望 拥有 
一 台 儿 童 自行 车 。 感 谢 妻 子 阿 巧 对 我 的 耐心 和 为 家 庭 的 付出 。 感 谢 岳 








父 、 盏 母 这 几 年 来 对 小 雪 和 我 们 整个 家 寿 的 照顾 ， 让 我 没有 后 顾 之 忧 。 
还 要 感谢 我 的 父 垂 和 妹妹 ， 他 们 对 我 事业 的 支持 和 工 励 是 我 前 进 的 动 
力 。 在 我 写作 本 书 的 同时 ， 老 爸 正 在 富 春 江 昱 代表 哈尔滨 电机 厂 监 督 肥 
电机 组 的 制造 ， 而 且 也 在 写 一 本 监 造 手册 方面 的 书 ， 抱 歉 老 爸 ， 我 先 完 
成 了 。:) 





薪 鲍 (http://www.ossxp.com/ ) 
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[3] http:/ /wiki.list.org/ display/ DEV/Home 


[4] http:/ /blog.ossxp.com/ 


第 1 篇 ” 初 识 Git 


Git 是 一 于 分 布 式 版 本 控制 系统 ， 有 别 于 CVS 和 SVN 等 集中 式 版 本 
控制 系统 ，Git 可 以 让 研发 团队 更 加 高 效 地 协同 工作 ， 从 而 提高 生产 
率 。 使 用 Git， 开 友人 员 的 工作 不 会 因为 频 紧 地 遭遇 提交 冲突 而 中 断 ， 
管理 人 员 也 无 须 为 数据 的 备份 而 担心 。 经 过 Linux 这 样 的 庞大 项 目的 考 
验 之 后 ，Git 被 证 明 可 以 胜任 任何 规模 的 团队 ， 即 便 团队 成 员 分 布 于 世 
界 各 地 。 





Git 是 开源 社区 奉献 给 每 一 个 人 的 宝贝 ， 用 好 它 不 仅 可 以 实现 个 人 
的 知识 积累 、 保 护 好 自己 的 数据 ， 而 且 还 能 与 他 人 分 圣 自 己 的 成 果 。 这 
在 其 他 的 很 多 版 本 控制 系统 中 是 不 可 想象 的 。 你 会 为 个 人 的 版 本 控制 而 
化 费 高 昂 的 费用 去 购买 商业 版 本 控制 工具 吗 ? 你 会 去 使 用 必须 搭建 额外 
的 服务 器 才能 使 用 的 版 本 控制 系统 吗 ? 你 会 把 “ 鸡 皇 ? 放 在 具有 单 点 故 
隐 、 服 务 器 软 硬 件 有 可 能 衣 省 的 唯一 的 “篮子 ?里 吗 ? 如 果 你 不 会 ， 那 么 


选择 Git， 一 定 是 最 明智 的 选择 。 








本 篇 我 们 首先 用 一 章 的 内 容 来 回顾 一 下 版 本 控制 的 历史 ， 并 以 此 向 
版 本 控制 的 前 辈 CVS 和 SVN 致 敬 。 第 2 章 会 通过 一 些 典 型 的 版 本 控制 实 
例 向 您 展示 Git 独 特 的 魅力 ， 让 您 爱 上 Git。 在 本 篇 的 最 后 一 章 会 介绍 Git 
在 Linux、Mac OS X 及 Windows 下 的 安装 和 使 用 ， 这 是 我 们 进一步 研究 
Git 的 基础 。 





二) 在 这 里 有 必要 纠正 一 下 Git 的 发 音 。 一 种 错误 是 按照 单个 字母 
来 发 音 ， 另 外 一 种 更 为 普遍 的 错误 是 把 整个 单词 读 作 “ 技 特 ”“， 实 际 上 
Git 中 字母 G 的 发 音 与 下 列 单词 中 的 G 类 似 : GOD、GIVES、GREAT、 
GIFT。 因 此 Git 正 确 的 发 音 应 该 听 起 来 像 是 “ 歌 易 特 ”。 本 书 的 英文 名 


为 《Got Git》， 当 面 对 这 样 的 书 名 时 您 还 会 把 Git 读 错 吗 ? 


第 1 革 版 本 控制 的 前 世 和 今生 


除了 茫然 未 知 的 宇 害 ， 几 乎 任何 事物 都 是 从 无 到 有 ， 从 简陋 到 完 
普 。 随 着 时 间 和 车 轮 的 深 深 回 前 ， 历 史 被 抛 在 身后 逐渐 远 去 ， 如 同 我 们 的 
现代 社会 ， 世 界 大 同 ， 到 人 处 都 是 忙碌 和 喧嚣， 再 也 看 不 到 已 经 远 去 的 刀 
耕 火 种 、 男 耕 女 织 的 慢 生 活 岁 月 。 


版 本 控制 系统 是 一 个 另类 。 虽 然 其 历史 并 不 短 特 ， 也 有 几 十 年 ， 但 
古 它 的 演进 进程 却 一 直 在 社会 的 各 个 角落 重复 着 ， 而 且 惊人 的 相似 。 有 
的 人 从 未 使 用 甚至 从 未 听 说 过 版 本 控制 系统 ， 他 和 他 的 团队 就 像 俘 留 在 
黑暗 的 史前 时 代 ， 任 由 数据 自生 目 灭 。 有 的 人 使 用 着 有 几 十 年 历史 的 
CVS 或 其 改 展 版 Subversion， 让 时 间 空 耗 在 网 络 连 接 的 等 竺 中 。 以 Git 为 
代表 的 分 布 式 版 本 控制 系统 已 经 风靡 整个 开源 社区 ， 正 等 得 你 的 徘 近 。 


1.1 黑暗 的 史前 时 代 


谈 及 远古 ， 人 们 总 爱 以 “黑暗 ”来 形容 。 黑 暗 实 际 上 指 的 是 秩序 和 工 
具 的 医 乏 ， 而 不 是 自然。 如 果 以 自然 环境 而 论 ， 由 于 工业 化 和 城市 化 对 
环境 的 破坏 ， 现 今 才 是 最 黑暗 的 年 代 。 对 于 软件 开发 来 说 也 是 如 此 ， 在 
C 语 言 一 统 天 下 的 日 子 里 我 们 的 选择 很 简单 ， 如 今 面 临 Java、.Net 和 脚本 
语言 时 ， 我 们 的 选择 变 得 复杂 起 来 ， 但 是 从 工具 和 秩序 上 讲 ， 过 去 的 年 


代 是 黑暗 的 。 











回顾 一 下 我 经 历 的 版 本 控制 的 “史前 时 代 ” 吧 。 在 大 学 里 ， 代 码 分 散 
地 拷贝 在 各 个 软盘 中 ， 最 终 我 被 搞 糊 涂 ， 不 知道 哪个 软盘 中 的 代码 是 最 
优 的 ， 因 为 最 新 并 非 最 优 ， 失 败 的 重 构 会 毁 掉 原 来 尚 能 运作 的 代码 。 在 
我 工作 的 第 一 年 ， 代 码 的 管理 并 未 得 到 改善 ， 还 是 以 简单 的 目录 拷贝 进 
行 数据 的 备份 ， 三 四 个 程序 员 利 用 文件 服务 器 的 共享 目录 进行 协同 ， 公 
共 类 库 和 头 文件 在 操作 过 程 中 相互 覆盖 ， 痛 苦 不 堪 。 很 明显 ， 那 时 我 尚 
不 知道 版 本 控制 系统 为 何 物 。 我 的 版 本 控制 史前 时 代 一 直 延 续 到 2000 
年 ， 那 时 CVS 已 经 诞生 了 14 年 ， 而 我 在 那 时 对 CVS 还 一 无 所 知 。 











实际 上 上， 即便 是 在 CVS 出 现 之 前 的 “史前 时 代 ”*， 也 已 经 有 了 非常 好 
用 的 用 于 源码 比较 和 打 补 丁 的 工具 : diff 和 patch， 它 们 今天 生命 力 依 然 
项 强 。 大 名 易 易 的 Linus Torvalds 先 生 〈Linux 之 父 ) 也 对 这 两 个 工具 偏 


爱 有 加 ， 在 1991~2002 年 之 间 ，Linus 一 直 兢 固 地 使 用 dif、patch 和 tar 包 
管理 着 Linux 的 代码 ， 昌 然 不 断 有 人 提醒 他 有 CVS 的 存在 中。 


那么 来 看 看 diff 和 patch， 熟 悉 它们 将 对 理解 版 本 控制 系统 〈 差 异 存 
储 ) 和 使 用 版 本 控制 系统 〈 代 码 比较 和 冲突 解决 ) 都 有 莫大 的 好 处 。 





1. 用 diff 命 令 比 较 两 个 文本 文件 或 目录 的 差异 


先 来 构造 两 个 文件 : 
文件 hello 文件 world 

应 该 杜绝 文章 中 的 错 别 子 ”。 应 该 杜绝 文章 中 的 错别字 。 
但 是 无 论 使 用 但 是 无 论 使 用 
* 全 拼 ， 双 拼 * 全 拼 ， 双 拼 
* 还 是 五 和 * 还 是 五 和 
是 人 就 有 可 能 犯错 ， 软 件 更 是 如 此 。 是 人 就 有 可 能 犯错 ， 软 件 更 是 如 此 。 
犯 了 错 ， 就 要 扣 工 资 ! 改正 的 成 本 可 能 会 很 高 。 
改正 的 成 本 可 能 会 很 高 。 但 是 “只 要 眼球 足够 多 ， 所 有 Bug 都 好 捉 ”， 


这 就 是 开源 的 哲学 之 一 。 








( 注 : 此 处 是 故意 将 “ 字 ” 写 成 * 子 ”， 以 便 两 个 文件 进行 差异 比 
较 。) 


对 这 两 个 文件 执行 diff 命 令 ， 并 通过 输出 重 定向 ， 将 差异 保存 在 
diff.txt 文 件 中 。 





$ diff -u hello world > diff.txt 





上 面 执行 diff 命 令 的 -u 参 数 很 重要 ， 使 得 差异 输出 中 带 有 上 下 文 。 
打开 文件 diff.txt， 会 看 到 其 中 的 差异 比较 结果 。 为 了 说 明 方 便 ， 为 每 一 


行 增添 了 行 号 。 











- hello 2010-09-21 17:45:33.551610940 +0800 
+++ world 2010-09-21 17:44:46.343610465 +0800 
@@ -1, 4 +1, 4 @@ 

-应 该 杜绝 文章 中 的 错 别 子 。 

+ 应 该 杜绝 文章 中 的 错别字 。 
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如 此 。 
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13 - 犯 了 错 ， 就 要 扣 工 资 ! 
15 ”改正 的 成 本 可 能 会 很 高 。 


17 + 但 是 “只 要 眼球 足够 多 ， 所 有 Bug 都 好 捉 ”， 
18 + 这 就 是 开源 的 哲学 之 一 。 





























上 面 的 又 异 文件 ， 可 以 这 么 理解 : 


. 第 1 行 和 第 2 行 分 别 记录 了 原始 文件 和 目标 文件 的 文件 名 及 时 间 
被 。 以 三 个 减 号 (---) 开始 的 行 标识 的 是 原始 文件 ， 以 三 个 加 号 


(+++) 开始 的 行 标识 的 是 目标 文件 。 


“ 在 比较 内 容 中 ， 以 减 号 (-) 开始 的 行 是 只 出 现在 原始 文件 中 的 
行 ， 例 如 : 第 4、13、14 行 。 


- 在 比较 内 容 中 ， 以 加 号 〈+) 开始 的 行 是 只 出 现在 目标 文件 中 的 


一 


村， 例如 : 第 5 行 和 16-18 行 。 


` 在 比较 内 容 中 ， 以 空格 开始 的 行 ， 是 在 原始 文件 和 目标 文件 中 都 
出 现 的 行 ， 例如: 第 6-8、10-12 和 第 15 行 。 这 些 行 是 用 作 差 异 比较 的 上 


下 有 


- 第 3-8 行 是 第 一 个 差异 小 节 。 每 个 差异 小 节 以 一 行 差异 定位 语句 


开始 。 第 3 行 就 是 一 条 差异 定位 语句 ， 其 前 后 分 别 用 两 个 @ 进 行 标识 。 


. 第 3 行 定 位 语句 中 -1，4 的 含义 是 : 本 差异 小 节 的 内 容 相 当 于 原始 
文件 的 从 第 1 行 开 始 的 4 行 。 而 第 4、6、7、8 行 是 原始 文件 中 的 内 容 ， 加 


起 来 刚好 是 4 行 。 


第 3 行 定位 语句 中 +1，4 的 含义 是 : 本 差异 小 节 的 内 容 相当 于 目标 
文件 的 从 第 1 行 开始 的 4 行 。 而 第 5、6、7、8 行 是 目标 文件 中 的 内 容 ， 加 
起 来 刚好 是 4 行 。 


:因为 命令 diff 是 用 于 行 比较 的 ， 所 以 即使 改正 了 一 个 字 ， 也 显示 
为 一 整 行 的 修改 (参见 差异 文件 第 4、5 行 ) 。Git 对 diff 进 行 了 扩展 ， 并 
且 还 提供 一 种 逐 词 比较 的 差异 比较 方法 ， 参 见 本 书 第 2 篇 的 第 11.4.4 小 


-六 
PP。 


~ 


第 9-18 行 是 第 二 个 差异 小 节 。 第 9 行 是 一 条 差异 定位 语句 。 


“第 9 行 定位 语句 中 -6，6 的 含义 是 : 本 差异 小 节 的 内 容 相当 于 原始 


文件 的 从 第 6 行 开 始 的 6 行 。 第 10-15 行 是 原始 文件 中 的 内 容 ， 加 起 来 刚好 


征 6 行 。 


` 第 9 行 定位 语 多 中 +6，7 的 含义 是 : 本 差异 小 节 的 内 容 相 当 于 目标 
文件 的 从 第 6 行 开始 的 7 行 。 而 第 10-12、15-18 行 是 目标 文件 中 的 内 容 ， 
加 起 来 刚好 是 7 行 。 


2. 命 令 patch 相 当 于 diff 的 反 回 操作 


有 了 hello 和 diff.txt 文 件 ， 可 以 放心 地 将 world 文 件 删除 或 用 hello 文 件 
将 world 文 件 窗 新 。 用 下 面 的 命令 可 以 还 原 world 文 件 : 





$ cp hello world 
$ patch world < diff.txt 





也 可 以 保留 world 和 diff.txt 文 件 ， 删 除 hello 文 件 或 用 word 文 件 将 hello 
文件 履 羡 。 用 下 面 的 命令 可 以 恢复 hello 文 件 : 





$ cp world hello 
$ patch -R hello < diff.txt 








命令 diff 和 patch 还 可 以 对 目录 进行 比较 操作 ， 这 也 就 是 Linus 在 
1991~2002 年 用 于 维护 Linux 不 同 版 本 间 差 异 的 办 法 。 在 没有 版 本 控制 系 
统 的 情况 下 ， 可 以 用 此 命令 记录 并 保存 改动 前 后 的 差异 ， 还 可 以 将 差异 
文件 注入 版 本 控制 系统 (如 果 有 的 话 )。 





标准 的 dif 和 patch 命 令 存在 一 个 局 限 ， 就 是 不 能 对 二 进 制 文件 进行 
处 理 。 对 二 进 制 文件 的 修改 或 添加 会 在 差异 文件 中 缺失 ， 进 而 丢失 对 二 
进 制 文件 的 改动 或 添加 。Git 对 关 异 文件 格式 提供 了 扩展 文 持 ， 文 持 二 
进 制 文件 的 比较 ， 解 决 了 这 个 问题 。 这 一 点 可 以 参考 本 书 第 7 访 第 38 章 
的 相关 内 容 。 








[1] Linus Torvalds 于 2007 年 5 月 3 日 在 Google 的 演讲 : 


http://www.youtube.com/watch?v=4XpnKHJAok8 


1.2 CVS 一 开局 版 本 控制 大 爆发 


CVS (Concurrent Versions System ) (1 诞生 于 1985 年 ， 是 由 荷兰 阿 
姆 斯 特 丹 VU 大 学 的 Dick Grune 教 授 实现 的 。 当 时 Dick Grune 和 两 个 学 生 
共同 开发 一 个 项 目 ， 但 是 三 个 人 的 工作 时 间 无 法 协调 到 一 起 ， 人 迫切 需要 
一 个 记录 和 协同 开发 的 工具 软件 。 于 是 Dick Grune 通 过 脚本 语言 对 
RCS (一 个 针对 单独 文件 的 版 本 管理 工具 〉 进 行 封 装 ， 设 计 出 有 史 以 来 
第 一 个 被 大 规模 使 用 的 版 本 控制 工具 。Dick 教 授 的 网 站 上 介绍 了 CVS 的 
这 段 早 期 历史 。 辣 


“在 1985 年 的 一 个 糟糕 的 秋 日 里 ， 我 在 校 汽车 站 等 车 回 家 ， 脑 海里 
一 直 纠 结 着 一 件 事 一 一 如 何 处 理 RCS 文 件 、 用 户 文件 (工作 区 ) 和 
Entries 文 件 的 复杂 关系 ， 有 的 文件 可 能 会 缺失 、 冲 突 、 删 除 ， 等 等 。 我 
的 头 有 些 尝 了 ， 于 是 决定 画 一 个 大 表 ， 将 复杂 的 关联 画 在 其 中 ， 看 看 出 
来 的 结果 是 什么 样 的 …… " 





1986 年 Dick 通 过 新 闻 组 发 布 了 CVS，1989 年 Brian Berliner 用 C 语 言 
将 CVS 进 行 了 重 写 。 


从 CVS 的 历史 可 以 看 出 ，CVS 不 是 设计 出 来 的 ， 而 是 被 实际 需 
要 “ 表 ? 出 来 的 ， 因 此 根据 “实用 为 上 ”的 原则 ， 借 用 了 已 有 的 针对 单一 文 
件 的 版 本 管理 工具 RCS。CVS 和 采用 客户 器 /服务 器 架构 设计 ， 版 本 库 位 于 


服务 嚣 端 ， 实 际 上 就 是 一 个 RCS 文 件 容器 。 每 一 个 RCS 文 件 以 <:，v” 作 为 
文件 名 后 级 ， 用 于 保存 对 应 文件 的 每 一 次 更 改 历史 。RCS 文 件 中 只 保留 
一 个 版 本 的 完全 拷贝 ， 其 他 历次 更 改 仅 将 差异 存储 其 中 ， 使 得 存储 变 得 
非常 有 效率 。 我 在 2008 年 设计 了 一 个 SVN 管 理 后 台 pySvnManager 1 ， 
实际 上 也 采用 了 RCS 作 为 SVN 授 权 文 件 的 变更 记录 的 “数据 库 ”。 











图 1-1 展 示 了 CVS 版 本 控制 系统 的 工作 原理 ， 可 以 看 到 作为 RCS 文 件 
容器 的 CVS 版 本 库 和 工作 区 目录 结构 的 一 一 对 应 关系 。 








CVS 这 种 实现 方式 的 最 大 好 处 就 是 简单 。 把 版 本 库 中 任意 一 个 目录 
拿 出 来 就 可 以 成 为 另外 一 个 版 本 库 。 如 果 将 版 本 库 中 的 一 个 RCS 文 件 重 
命名 ， 工 作 区 检 出 的 文件 名 也 会 相应 地 改变 。 这 种 低 成 本 的 服务 器 管理 
模式 成 为 很 多 CVS 粉 丝 至 今 不 愿 离开 CVS 的 原因 。 











CVS 的 出 现 让 软件 工程 师 认 识 到 了 原来 还 可 以 这 样 工作 。CVS 成 功 
地 为 后 来 的 版 本 控制 系统 确立 了 标准 ， 像 提交 说 明 (commitlog) 、 检 
入 (checkin) 、 检 出 (checkout) 、 里 程 碑 〈tag) 、 分 支 (branch) 等 
概念 在 CVS 中 早 就 已 经 确立 。CVS 的 命令 行 格式 也 被 后 来 的 版 本 控制 系 
统 竞 相模 仿 。 


[ey CVS 版 本 库 ie 本 = 


V1 


_ ; V2=V1+A1 
项 目 一 V3=V2+a2 | 工作 区 (版 本 Tag1) 
; V4=V3+A3 :Tag1 : 


和 V4+A4 :Tag2; 一 
src ee 二 
a 2 RE v4 
三 |hellocv v2- sb 
“3 V2=VI+A1 Tag1 WO , 
V3=V2+A2: Tag2 : E | v2 
三 |hello.hyv -~ A 


ee 


『 doc 2» V1: Tag2 
= Readmey 学 i 
| Makefile.. 
SS Makefile,v Wi 
Vol  ， ， 注 : 工作 区 中 咯 去 目录 CVS 


图 1-1 CVS 版 本 控制 系统 示意 图 


在 2001 年 ， 我 正 为 使 用 CVS 激 动 不 已 的 时 候 ， 公 司 领导 要 求 采 用 和 
美国 研发 部 门 同 样 的 版 本 控制 解决 方案 。 于 是 ， 我 的 项 目 组 率先 进行 了 
从 CVS 到 该 商业 版 本 控制 工具 的 迁移 所 。 虽 然 商业 版 本 控制 工具 有 更 漂 
亮 的 界面 及 更 好 的 产品 整合 性 ， 但 是 就 版 本 控制 本 身 而 言 ， 了 商业 版 本 控 
制 工具 存在 着 如 下 缺陷 。 














采用 黑 盒 子 式 的 版 本 库 设 计 。 让 人 提 摸 不 透 的 版 本 库 设 计 ， 最 主 
要 的 目的 可 能 就 是 阻止 用 户 再 迁移 到 其 他 平台 。 


` 缺乏 版 本 库 整 理工 具 。 如 果 有 一 个 文件 《如 记录 核弹 引爆 客 码 的 


文件 ) 检 入 到 版 本 库 中 ， 就 无 法 再 彻底 移 除 它 。 


` 商业 版 本 控制 工具 很 难为 个 人 提供 版 本 控制 解决 方案 ， 除 非 个 人 
愿意 花费 高 昂 的 许可 证 费用 。 


. 商业 版 本 控制 工具 注定 是 小 众 软件 ， 新 员工 的 培训 成 本 不 可 忽 


视 。 


上 述 丙 业 版 本 控制 系统 的 缺点 恰恰 是 CVS 及 其 他 开源 版 本 控制 系 
统 的 优点 。 但 在 经 历 了 最 初 的 成 功 之 后 ，CVS 也 尺 显 疲 态 : 





. 服务 器 端 松 散 的 RCS 文 件 导 致 在 建立 里 程 碑 或 分 支 时 效率 不 高 ， 
服务 器 端 文件 越 多 ， 速 度 越 慢 。 


` 分 支 和 里 程 碑 不 可 见 ， 因 为 它们 被 分 散 地 记录 在 服务 器 端的 各 个 
RCS 文 件 中 。 

. 合并 困难 重重 ， 因 为 缺乏 对 合并 的 追踪 ， 从 而 导致 重复 合并 ， 引 
次 严重 证 窑 。 

. 缺乏 对 原子 提交 的 支持 ， 会 导致 客户 端 向 服务 器 端 提交 不 完整 的 


数 据 9 


不 能 优化 存储 内 容 相 同 但 文件 名 不 同 的 文件 ， 因 为 在 服务 器 端 每 
个 文件 都 是 单独 进行 差异 存储 的 。 


` 不 能 对 文件 和 目录 的 重 命名 进行 版 本 控制 ， 虽 然 直接 在 服务 器 端 
修改 RCS 文 件 名 可 以 让 改名 后 的 文件 保存 历史 ,但 是 这 样 做 实际 上 会 破 
坏 历史 。 


CVS 的 成 功 导 致 了 版 本 控制 系统 的 大 爆 反 ， 各 式 各 样 的 版 本 控制 系 
统 如 雨 后 春 算 般 诞生 了 。 新 的 版 本 控制 系统 或 多 或 少 地 解决 了 CVS 版 本 
控制 系统 存在 的 问题 。 在 这 些 版 本 控制 系统 中 ， 最 典型 的 就 是 
Subversion (SVN) 。 


[1] http://www.nongnu.org/ cvs/ 
[2] http://dickgrune.com/ Programs/CVS.orig/ 
[3] http://pysvnmanager.sourceforge.net 


四 于 是 就 有 了 这 篇 文章 : http://www.worldhello.net/doc/cvs_vs_starteam 


1.3 ”SVN 一 一 集中 式 版 本 控制 集大成 者 


Subversion 0 ， 由 于 其 命令 行 工具 名 为 swn， 因 此 通常 被 简称 为 
SVN。SVN 由 CollabNet 公 司 于 2000 年 资助 并 开始 开发 ， 目 的 是 创建 一 个 
更 好 用 的 版 本 控制 系统 以 取代 CVS。SVN 的 前 期 开发 使 用 CVS 做 版 本 控 
制 ， 到 了 2001 年 ，SVN 己 经 可 以 用 于 自己 的 版 本 控制 了 中。 


我 开始 真正 关注 SVN 是 在 2005 年 ， 那 时 SVN 正 经 历 着 后 端 存储 上 的 
变革 ， 即 从 BDB〔 简 单 的 关系 型 数据 库 ) 到 FSFS (文件 数据 库 ) 的 转 
变 。 相 对 于 BDB 而 言 ，FSFS 具 有 稳定 、 免 维护 和 实现 的 可 视 性 高 等 优 
点 ， 于 是 我 马上 就 被 SVN 吸 引 了 。 图 1-2 展 示 了 SVN 版 本 控制 系统 的 工 
作 原 理 。 








| 入” SVN 版 本 库 入 客户 端 


gon [上 rf (a ro) 


“ ChangeSet #2 
M src/hello.c 





: A srclhello.h : a 

A srclhello.0......: 萎 r3 
“ChangeSet#3 = ee 

M src/hello.c 。 os 
: A src/hello.h 三 |hello.c i i 
A | eee ; 
: ChangeSet #4 三 |hello.h 

A doc/lReadme  : = 
ma doc 站 
.A Makefile 2 - a dvd ; 
: ChangeSet #6 |: 三 |Readme 

D src/hello.o ; 

三 | Makefile ws 


注 : 工作 区 中 略 去 目录 . svn 


图 1-2 SVN 版 本 控制 系统 示意 图 


SVN 的 每 一 次 提交 ， 都 会 在 服务 器 端的 dbrevs 和 db/revprops 目 录 下 
各 创建 一 个 以 顺序 数字 编号 命名 的 文件 。 其 中 ，db/revs 目 录 下 的 文件 
( 即 变 更 集 文件 ) 记 录 了 与 上 一 个 提交 之 间 的 差异 (字母 A 表示 新 增 ， 
M 表 示 修 改 ，DD 表 示 删 除 ) 。 在 db/revprops 目 录 下 的 同名 文件 (没有 在 
图 1-2 中 体现 ) 则 保存 着 提交 日 志 、 作 者 、 提 交 时 间 等 信息 。 这 样 设计 
的 好 处 有 : 





. 拥有 全 局 版 本 号 。 每 提交 一 次 ，SVN 的 版 本 号 就 会 自动 加 一 。 这 
为 SVN 的 使 用 提供 了 极 大 的 便利 。 回 想 CVS 时 代 ， 每 个 文件 都 拥有 各 自 
独立 的 版 本 号 (RCS 版 本 号 ) ， 要 想 获 得 全 局 版 本 号 ， 只 能 通过 手工 不 


断 地 建立 里 程 碑 来 实现 。 


. 实现 了 原子 提交 。SVN 不 会 像 CVS 那 样 出 现 文件 的 部 分 内 容 被 提 


交 而 其 余 的 内 容 没 有 被 提交 的 情况 。 


` 文件 名 不 受 限 制 。 因 为 服务 器 端 不 再 需要 建立 和 客户 端 文件 相似 
的 文件 名 ， 于 是 ， 文 件 的 命名 就 不 再 受 服务 器 操作 系统 的 字符 集 和 大 小 
写 的 限制 。 


` 文件 和 目录 重 命名 也 得 到 了 支持 。 


SVN 最 具有 特色 的 功能 是 轻 量 级 找 贝 ,例如 将 目录 trunk 找 贝 为 
branches/v1.x 只 相当 于 在 db/revs 目 录 中 的 变更 集 文件 中 用 特定 的 语法 做 
了 一 下 标注 ， 无 须 真正 的 文件 找 贝 。SVN 使 用 轻 量 级 拷贝 的 功能 ， 轻 松 
地 解决 了 CVS 存 在 的 里 程 碑 和 分 支 的 创建 速度 慢 又 不 可 见 的 问题 ， 使 用 
SVN 创 建 里 程 碑 和 分 文 只 在 肯 眼 之 间 。 








SVN 在 版 本 库 授权 上 也 有 改进 ， 不 再 像 CVS 那 样 依 赖 操作 系统 本 二 
对 版 本 库 目 录 和 文件 进行 授权 ， 而 是 采用 授权 文件 的 方式 来 实现 。 








SVN 还 有 一 个 创举 ， 束 是 在 工作 区 跟踪 目录 下 〈.svn 目 录 ) 为 当前 
目录 中 的 每 一 个 文件 都 保存 一 份 见 余 的 原始 拷贝 。 这 样 做 的 好 处 是 部 分 
命令 不 再 需要 网 络 连 接 ， 例 如 文件 修改 的 差异 比较 ， 以 及 错误 更 改 的 回 





正 征 由 于 这 些 内 亮 的 功能 特性 ， 才 使 得 SVN 在 CVS 之 后 诞生 的 诸多 
版 本 控制 系统 中 脱 刹 而 出 ， 成 为 开源 社区 一 时 的 新 穹 ， 也 成 为 当时 各 个 
企业 进行 版 本 控制 的 最 佳 选 择 之 一 。 


但 是 ， 相 对 于 CVS，SVN 在 本 质 上 并 没有 突破 ， 都 属于 集中 式 版 本 
控制 系统 。 即 一 个 项 目 只 有 唯一 的 一 个 版 本 库 与 之 对 应 ， 所 有 的 项 目 成 
员 都 通过 网 络 向 该 服务 器 进行 提交 。 这 样 的 设计 除了 容易 出 现 单 点 故障 
以 外 ， 在 查看 日 志和 提交 数据 等 操作 时 的 延迟 ， 会 让 基于 广域网 协同 工 
作 的 团队 抓 狂 。 





除了 集中 式 版 本 控制 系统 固有 的 问题 外 ，SVN 的 里 程 碑 和 分 支 的 设 
计 也 被 证 明 是 一 个 错误 ， 虽 然 这 个 错误 的 设计 使 得 SVN 拥 有 了 快速 创建 
里 程 碑 和 分 支 的 能 力 ， 但 是 这 个 错误 的 设计 也 导致 了 如 下 的 更 多 问题 。 





- 项 目 文件 在 版 本 库 中 必须 按照 一 定 的 目录 结构 进行 部 署 ， 否 则 就 
可 能 无 法 建立 里 程 碑 和 分 支 。 











我 在 项 目 咨询 过 程 中 见 过 很 多 团队 ， 直 接 在 版 本 库 的 根 目 录 下 创建 
项 目 文件 。 这 样 的 版 本 库 布 局 ， 在 需要 创建 里 程 碑 和 分 文 时 就 无 从 下 手 
了 ， 因 为 根 目录 是 不 能 找 贝 到 子 目录 中 的 。 所 以 SVN 的 用 户 在 创建 版 本 
库 时 必须 遵守 一 个 古怪 的 约定 : 先 创 建 三 个 顶级 目录 /trunk、/tags 
和 /branches。 





* 创建 里 程 碑 和 分 支 会 破坏 精心 设计 的 授权 。 











SVN 的 授权 是 基于 目录 的 ， 分 文 和 里 程 碑 也 被 视 为 目录 (和 其 他 日 
录 没 有 分 别 ) 。 因 此 每 次 创建 分 支 或 里 程 碑 时 ， 就 要 将 针对 /trunk 目 录 
及 其 子 目 录 的 授权 在 新 建 的 分 文 或 里 程 碑 上 重建 。 随 着 分 文 和 里 程 碑 数 
量 的 增多 ， 授 权 愈 加 复杂 ， 维 护 也 您 加 困难 。 


` 分 支 太 随意 从 而 导致 混乱 。SVN 的 分 支 创 建 非常 随意 : 可 以 基 
于 /trunk 目 录 创 建 分 支 ， 也 可 以 基于 其 他 任何 目录 创建 分 支 ， 因 此 SVN 
很 难 画 出 一 个 有 意义 的 分 支 图 。 再 加 上 一 次 提交 可 以 同时 包含 针对 不 同 
分 支 的 文件 变更 ， 使 得 事情 变 得 更 糟 。 


- 虽然 SVN 在 1.5 版 之 后 拥有 了 合并 追踪 功能 ， 但 这 个 功能 会 因为 混 
乱 的 分 支管 理 而 被 抵消 。 


2009 年 年 底 ，SVN 由 CollabNet 公 司 交 由 Apache 社 区 管理 ， 至 此 SVN 
成 为 了 Apache 组 织 的 一 个 子 项 目 沾 。 这 对 SVN 到 底 意 味 着 什么 ?是 开 
发 的 停滞 ? 还 是 新 的 开始 ?结果 如 何 我 们 将 拭目以待 。 


[1] http:/ /subversion.apache.org/ 
D] http://svnbook.red- 
bean.com/en/1.5/svn.intro.whatis.html#svn.intro.history 


[3] http:/ /en.wikipedia.org/wiki/ Apache_Subversion 


1.4 Git 一 Linus 的 第 二 个 伟大 作品 





Linux 之 父 Linus 是 坚定 的 CVS 反 对 者 ， 他 也 同样 地 反对 SVN。 这 就 
是 为 什么 在 1991-2002 这 十 余年 间 ，Linus 宁 可 以 手工 修补 文件 的 方式 维 
护 代码 ， 也 人 述 述 不 愿 使 用 CVS 的 原因 。 我 想 在 当时 要 想 劝 说 Linus 使 用 
CVS 只 有 一 个 办 法 : 把 CVS 服 务 器 请 进 Linus 的 卧室 ， 并 对 外 配 以 干 兆 带 


er 
Wo 


2002 年 至 2005 年 ，Linus 顶 着 开源 社区 精英 们 口 诛 笔 伐 的 压力 ， 选 
择 了 一 个 商业 版 本 控制 系统 BitKeeper 作 为 Linux 内 核 的 代码 管理 工具 叫 
。 BitKeeper 不 同 于 CVS 和 SVN 等 集中 式 版 本 控制 工具 ， 而 是 一 款 分 布 式 
版 本 控制 工具 。 








分 布 式 版 本 控制 系统 最 大 的 反 传统 之 处 在 于 ， 可 以 不 需要 集中 式 的 
版 本 库 ， 每 个 人 都 工作 在 通过 克隆 建立 的 本 地 版 本 库 中 。 也 就 是 说 每 个 
人 都 拥有 一 个 完整 的 版 本 库 ， 查 看 提交 日 志 、 提 交 、 创 建 里 程 碑 和 分 
文 、 合 并 分 支 、 回 退 等 所 有 操作 都 直接 在 本 地 完成 而 不 需要 网 络 连接 。 
每 个 人 部 是 本 地 版 本 库 的 主人 ， 不 再 有 谁 能 提交 谁 不 能 提交 的 限制 ， 加 
上 多 样 的 协同 工作 模型 (版 本 库 间 推 送 、 拉 回 ， 以 及 补丁 文件 传送 等 ) 
让 开源 项 目的 参与 度 有 爆发 式 增长 。 


2005 年 发 生 的 一 件 事 最 终 导 致 了 Git 的 诞生 。 在 2005 年 4 月 ，Andrew 


Tridgell〈 即 大 名 易 易 的 Samba 的 作者 ) 试图 对 BitKeeper 进 行 反 向 工程 ， 
以 开发 一 个 能 与 BitKeeper 交 互 的 开源 工具 。 这 激怒 了 BitKeeper 软 件 的 
所 有 者 BitMover 公 司 ， 要 求 收回 对 Linux 社 区 免费 使 用 BitKeeper 的 授权 
中 。 迫 不 得 已 ，Linus 选 择 了 自己 开发 一 个 分 布 式 版 本 控制 工具 以 替代 
BitKeeper。 以 下 是 Git 诞 生 过 程 中 的 大 事 记 站 : 





" 2005 年 4 月 3 日 ， 开 始 开发 Git。 


. 2005 年 4 月 6 日 ， 项 目 发 布 。 


2005 年 4 月 7 日 ，Git 就 可 以 作为 自身 的 版 本 控制 工具 了 。 


“2005 年 4 月 18 日 ，。 发 生 第 一 个 多 分 支 合 并 。 


. 2005 年 4 月 29 日 ，Git 的 性 能 就 已 经 达到 了 Linus 的 预期 。 


2005 年 6 月 16 日 ，Linux 内 核 2.6.12 发 布 ， 那 时 Git 已 经 在 维护 Linux 
核心 的 源 代码 了 。 


Linus 以 一 个 文件 系统 专家 和 内 核 设计 者 的 视角 对 Git 进 行 了 设计 ， 
其 独特 的 设计 让 Git 拥 有 非凡 的 性 能 和 最 为 优化 的 存储 能 力 。 完 成 原型 
设计 后 ， 在 2005 年 7 月 26 日 ，Linus 功 成 喘 退 ， 将 Git 的 维护 交 给 另外 一 个 
Git 的 主要 贡献 者 Junio C Hamano [4 ， 直 到 现在 。 


最 初 的 Git 除 了 一 些 核心 命令 以 外 ， 其 他 的 都 用 脚本 语言 开发 ， 而 


且 每 个 功能 都 作为 一 条 独立 的 命令 ， 例 如 死 隆 操 作用 gitrclone， 提 交 操 
作用 gitrcommit。 这 导致 Git 拥 有 庞大 的 命令 集 ， 使 用 习惯 也 和 其 他 版 本 
控制 系统 格格 不 入 。 随 着 Git 的 开发 者 和 使 用 者 的 增加 ，Git 也 在 逐渐 演 
变 ， 例 如 到 1.5.4 版 本 时 ， 将 一 百 多 个 独立 的 命令 封装 为 一 个 git 命 令 ， 使 
它 看 起 来 更 像 是 一 个 独立 的 工具 ， 也 使 Git 更 贴近 于 普通 用 户 的 使 用 习 


惯 。 


经 过 短 短 几 年 的 发 展 ， 众 多 的 开源 项 目 都 纷纷 从 SVN 或 其 他 版 本 控 
制 系统 迁移 到 Git。 虽 然 版 本 控制 系统 的 迁移 过 程 是 痛苦 的 ， 但 是 因为 
迁移 到 Git 会 带 来 开发 效率 的 极 大 提升 ， 以 及 巨大 的 效益 ， 所 以 很 快 就 

忘记 迁移 的 痛苦 过 程 ， 而 且 很 快 就 会 适应 新 的 工作 模式 。 在 Git 的 官 
方 网 站 上 列 出 了 几 个 使 用 Git 的 重量 级 项 目 ， 每 一 个 都 是 人 们 耳熟能详 
的 ， 除 了 Git 和 Linux 内 核 外 ， 还 有 Perl、Edlipse、Gnome、KDE、Qt、 
Ruby on Rails、Android、PostgreSQL、Debian、X.org， 当 然 还 有 GitHub 
的 上 百 万 个 项 目 。 











Git 虽 然 是 在 Linux 下 开发 的 ， 但 现在 已 经 可 以 跨 平 台 运行 在 所 有 主 
流 的 操作 系统 上 ， 包 括 Linux、Mac OS X 和 Windows 等 。 可 以 说 每 一 个 
使 用 计算 机 的 用 户 都 可 以 分 享 Git 带 来 的 便利 和 快乐 。 


[1] http:/ /en.wikipedia.org/wiki/ BitKeeper 
[2] http:/ /en.wikipedia.org/wiki/ Andrew_Tridgell 


[3] http:/ /en.wikipedia.org/wiki/ Git_%28software%Y29 


[4] http:/ /marc.info/?l=git&m=112243466603239 


第 2 章 ” 爱 上 Git 的 理由 


本 章 将 通过 一 些 典 型 应 用 展示 Git 作 为 版 本 控制 系统 的 独特 用 法 ， 
不 熟悉 版 本 控制 系统 的 读者 可 以 通过 这 些 示例 对 版 本 控制 拥有 感性 的 认 
识 。 如 果 是 有 经 验 的 读者 ， 示 例 中 Git 和 SVN 的 对 照 可 以 让 您 体会 到 Git 
的 神奇 和 强大 。 本 章 将 列举 Git 的 一 些 内 亮 特性 ， 期 待 能 够 让 您 爱 上 
Git。 


2.1 日 工作 备份 








当 我 开始 撰写 本 书 时 才 明 白 写 书 真 的 是 一 个 辛 苗 活 。 如 何 让 辛苦 的 
工作 不 会 因为 笔记 本 硬盘 的 意外 损坏 而 丢失 ? 如 何 防范 灾害 而 不 让 一 个 
篮子 里 的 鸡 各 都 毁 于 一 旦 ? 下 面 就 介绍 一 下 我 在 写本 书 时 是 如 何 使 用 
Git 进 行文 稿 备份 的 ， 请 看 图 2-1。 





公司 局 域 网 数据 中 心 
Eee 


一 
206.221.217.* 


192.168.0.2 \ 


192.168.0.100 








图 2-1 利用 Git 做 数据 的 备份 


如 图 2-1 所 示 ， 我 的 笔记 本 在 公司 局 域 网 里 的 IP 地 址 是 
192.168.0.100， 公 司 的 Git 服 务 器 的 人 P 地 址 是 192.168.0.2。 公 司 使 用 动态 
IP 上 网 因而 没有 固定 的 外 网 IP， 但 是 公司 在 数据 中 心 有 托 管 服务 器 ， 拥 
有 固定 的 人 P 地 址 ， 其 中 一 台 服 务 器 用 作 Git 服 务 器 镜像 。 


我 的 写 书 习惯 大 概 是 这 样 : 在 写 完 一 个 小 节 或 是 画 完 一 张 图 后 ， 我 
会 执行 下 面 的 命令 提交 一 次 。 每 一 天 平均 提交 3-5 次 。 提 交 是 在 本 地 完 
成 的 ， 因 此 在 图 中 没有 表示 出 来 。 














$ git add -u # 如 果 创 建 了 新 文件 ， 可 以 执行 git add -i 命令 。 
$ git commit 


下 班 后 ， 我 会 执行 一 次 推送 操作 ， 将 我 在 本 地 Git 版 本 库 中 的 提交 
同步 到 公司 的 Git 服 务 器 上 。 相 当 于 图 2-1 中 的 步骤 (D。 


$ git push 





因为 公司 的 Git 服 务 器 和 腊 地 数据 中 心 的 Git 服 务 器 建立 了 镜像 ， 所 
以 每 当 我 向 公司 内 网 服务 器 推送 的 时 候 ， 就 会 自动 触发 从 内 网 服务 器 到 
外 网 Git 服 务 器 的 镜像 操作 。 这 相当 于 图 2-1 中 的 步骤 名， 步骤 是 自动 
执行 的 ， 无 须 人 工 干 预 。 图 2-1 中 标记 为 mirror 的 版 本 库 就 是 Git 镜 像 版 本 
库 ， 该 版 本 库 只 向 用 户 提 供 只 读 访 问 服务 ， 而 不 能 对 其 进行 写 操作 〈 推 
人 








从 图 2-1 中 可 以 看 出 ， 我 的 每 日 工作 保存 有 三 个 拷贝 ， 一 个 在 笔记 
本 中 ， 一 个 在 公司 内 网 的 服务 器 上 ， 还 有 一 个 在 外 网 的 镜像 版 本 库 中 。 
鸡 香 分 别 装 在 了 三 个 篮子 里 。 





关于 如 何 架 设 可 以 实时 镜像 的 Git 服 务 器 ， 会 在 本 书 第 5 篇 第 30 章 中 


O 


详细 介 


| 


2.2 ”异地 协同 工作 


为 了 能 够 加 快 写 书 的 进度 ， 获 夜 是 必须 的 ， 这 就 出 现 了 在 公司 和 家 
里 两 地 工作 同步 的 问题 。 图 2-2 用 于 说 明 我 是 如 何 解决 两 地 工作 同步 问 


题 的 。 








192.168.0.126 192.168.0.100 






10.0.0.100 


图 2-2 ”利用 Git 实 现 异 地 工作 协同 


我 在 家 里 的 电脑 [PP 地址 是 10.0.0.100 (家 里 也 有 一 个 小 局 域 网 ) 。 如 
果 在 家 里 有 时 间 工 作 的 话 ， 首 先 要 做 的 就 是 图 2-2 中 步骤 @ 的 操作 : 将 
mirror 版 本 库 中 的 数据 同步 到 本 地 。 只 需要 一 条 命令 就 好 了 了: 








$ git pull mirror master 


然后 在 家 里 的 电脑 上 继续 编写 书稿 并 提交 。 妆 准备 完成 一 天 的 工作 
后 ， 就 执行 下 面 的 命令 ， 相 当 于 图 2-2 中 步 又 由 的 操作 : 将 在 家 中 的 提 


交 推 送 到 标记 为 home 的 版 本 库 中 。 


$ git push home 





为 什么 还 要 再 引入 另外 一 个 名 为 home 的 版 本 库 呢 ? 使 用 mirror 版 本 
库 不 好 么 ? 不 要 起 了 mirror 版 本 库 只 是 一 个 镜像 库 ， 不 能 提供 写 操作 。 


当 一 早 到 公司 ， 开 始 动笔 写 书 之 前 ， 先 要 执行 图 2-2 中 步骤 器 的 操 
作 ， 从 home 版 本 库 将 家 里 做 的 提交 同步 到 公司 的 电脑 中 。 


$ git pull home master 











公司 的 小 赃 是 我 这 本 书 的 忠实 读者 ， 每 当 有 新 章节 完成 ， 他 都 会 执 
行 图 2-2 中 步骤 6) 的 工作 ， 从 公司 内 网 服务 器 获取 我 最 新 的 文稿 。 


$ git pull 





一 旦 发 现 文 字 错 误 ， 小 崔 会 直接 在 文稿 中 修改 ， 然 后 推送 到 公司 的 
服务 器 上 【图 2-2 中 步骤 @) 。 当 然 他 的 这 个 推送 也 会 自动 同步 到 外 网 
的 mirror 版 本 库 。 





$ git push 





而 我 只 要 执行 git pull 操 作 就 可 以 获得 小 崔 对 文稿 的 修订 (图 2-2 中 的 
步骤 的 ) 。 采 用 这 种 工作 方式 ， 文 稿 葛 然 分 布 在 5 台电 脑 上 拥有 6 个 找 





贝 ， 真 可 谓 狼 兔 三 宣 。 不 ， 比 狭 免 还 要 多 三 宣 。 


在 本 节 中 ， 出 现在 Git 命 令 中 的 mirror 和 home 是 和 工作 区 关联 的 远程 
版 本 库 。 关 于 如 何 注 册 和 使 用 远程 版 本 库 ， 请 参见 本 书 第 3 篇 第 19 章 中 
的 内 容 。 





2.3 ”现场 版 本 控制 





所 谓 现场 版 本 控制 ， 就 是 在 客户 现场 或 在 产品 部 羞 的 现场 进行 源 代 
码 的 修改 ， 并 在 修改 过 程 中 进行 版 本 控制 ， 以 便 在 完成 修改 后 能 够 将 修 
改 结果 甚至 修改 过 程 一 并 带 走 ， 并 能 够 将 修改 结果 合并 至 项 目 对 应 的 代 
码 库 中 。 





1.SVN 的 解决 方案 





如 琳 使 用 SVN 进 行 版 本 控制 ， 首 先 要 将 服务 器 上 部 著 的 产品 代码 目 
录 变 成 SVN 工 作 区 ， 这 个 过 程 不 仅 不 简单 ， 而 且 会 显得 很 索 珊 ， 最 后 将 
改动 结果 导出 也 非常 不 方便 ， 具 体操 作 过 程 如 下 。 





(1) 在 其 他 位 置 建立 一 个 SVN 版 本 库 。 





$ svnadmin create /path/to/repos/project1 





(2) 在 需要 版 本 控制 的 目录 下 检 出 刚刚 建立 的 空 版 本 库 。 


$ svn checkout file:///path/to/repos/project1 ， 








(3) 执行 添加 文件 操作 ， 然 后 执行 提交 操作 。 这 个 提交 将 是 版 本 
库 中 编写 为 1 的 提交 。 


$ svn add * 
$ svn ci -m "initialized" 


(4) 开始 在 工作 区 中 修改 文件 并 提交 。 


$ svn ci 


(5) 如 果 对 修改 结果 满意 ， 可 以 通过 创建 补丁 文件 的 方式 将 工作 
成 果 保 存 并 带 走 。 但 是 SVN 很 难 针 对 每 次 提交 逐一 创建 补丁 ， 一 般 用 下 
面 的 命令 与 最 早 的 提交 进行 比较 ， 以 创建 出 一 个 大 补丁 文件 。 





$ svn diff -ri > hacks.patch 


上 面 用 SVN 将 工作 成 果 导 出 的 过 程 存 在 一 个 致命 的 缺陷 ， 就 是 SVN 
的 补丁 文件 不 文 持 二 进 制 文件 ， 因 此 采用 补丁 文件 的 方式 有 可 能 丢失 数 
据 ， 如 新 增 或 修改 的 图 形 文件 会 丢失 。 更 为 稳妥 但 也 更 为 复杂 的 方式 可 
能 要 用 到 svnadmin 命 令 将 版 本 库 导 出 。 命 令 如 下 : 








$ svnadmin dump --incremental -r2:HEAD \ 
/path/to/repos/project1/ > hacks.dump 








将 svnadmin 命 令 创 建 的 导出 文件 恢复 到 版 本 库 中 也 非常 具有 挑战 
性 ， 这 里 就 不 再 详细 说 明了 。 还 是 来 看 看 Git 在 这 种 情况 下 的 表现 吧 。 


2.Git 的 解决 方案 


与 SVN 将 产品 部 署 目录 转化 为 SVN 的 工作 区 相 比 ，Git 要 更 为 简 


单 ， 而 且 使 用 Git 导 出 提交 历史 也 更 为 简单 和 实用 ， 具 体操 作 过 程 如 
Ts 





(1) 创建 现场 版 本 库 。 和 直接 在 需要 版 本 控制 的 目录 下 执行 Git 版 本 
库 初 始 化 命令 。 


$ git init 





(2) 添加 文件 并 提交 。 


$ git add -A 
$ git commit -m "initialized" 


(3) 为 初始 提交 建立 一 个 里 程 碑 : “v1”。 





$ git tag vi 


(4) 开始 在 工作 区 中 工作 一 一 修改 文件 并 提交 。 





$ git commit -a 





(5) 当 对 修改 结果 满意 并 想 将 工作 成 果 保 存 融 走时 ， 可 以 通过 下 
面 的 命令 将 从 v1 开 始 的 历次 提交 逐一 导出 为 补丁 文件 。 转 换 的 补丁 文件 
都 包含 一 个 数字 前 级 ， 并 提取 提交 日 志 信 息 作为 文件 名 ， 而 且 补 丁 文件 
还 提供 对 二 进 制 文件 的 文 持 。 下 面 命令 的 输出 摘 目 本 书 第 3 篇 第 20 草 中 
的 实例 。 











$ git format-patch V1, .HEAD 
©0001-Fix-typo-help-to-help.patch 
©0002-Add-I18N-support.patch 
0003-Translate-for-Chinese.patch 





(6) 通过 邮件 将 补丁 文件 发 出 。 当 然 ， 也 可 以 通过 其 他 方式 将 补 
了 丁 文件 带 走 。 





$ git send-email *.patch 





Git 创 建 的 补丁 文件 使 用 了 Git 扩 展 格式 ， 因 此 在 导入 时 为 了 避免 数 
据 遗 漏 ， 要 使 用 Git 提 供 的 命令 而 不 能 使 用 GNU 的 patch 命 令 。 即 使 要 导 
入 的 不 是 Git 版 本 库 ， 也 可 以 使 用 Git 命 令 ， 具 体操 作 请 参见 本 书 第 7 篇 第 
38 章 中 的 相关 内 容 。 


2.4 避免 引入 辅助 目录 


很 多 版 本 控制 系统 都 要 在 工作 区 中 引入 辅助 目录 或 文件 ， 如 SVN 要 
在 工作 区 的 每 一 个 子 目 录 下 都 创建 .svn 目 录 ，CVS 要 在 工作 区 的 每 一 个 
子 目 录 下 都 创建 CVS 目 录 。 


这 些 辅 助 日 录 如 果 出 现在 服务 器 上 ， 尤 其 是 Web 服 务 器 上 是 非常 危 
险 的 ， 因 为 这 些 辅 助 目 录 下 的 Entries 文 件 会 暴露 出 目录 下 的 文件 列表 ， 
让 管理 员 精 心 配置 的 禁止 目录 浏览 的 努力 全 部 白费 。 








还 有 ，SVN 的 .svn 辅 助 目录 下 还 存在 文件 的 原始 拷贝 ， 在 文件 搜索 
时 结果 会 加 倍 。 如 果 你 曾经 在 SVN 的 工作 区 用 过 grep 命 令 进行 内 容 查 
找 ， 就 会 明白 我 指 的 是 什么 。 





Git 没 有 这 个 问题 ， 不 会 在 子 目 录 下 引入 讨厌 的 辅助 目录 或 文件 
(.gitignore 和 .gitattributes 文 件 不 算 ) 。 当 然 ，Git 还 是 要 在 工作 区 的 顶级 
目录 下 创建 名 为 .git 的 目录 《版 本 库 目录 ) ， 不 过 ， 如 果 你 认为 唯一 的 
一 个 .git 目 录 也 过 于 碍 眼 ， 可 以 将 其 放 到 工作 区 之 外 的 任意 上 日 录 。 一 旦 
这 么 做 了 ， 在 执行 Git 命 令 时 ， 就 要 通过 命令 行 (--git-dir) 或 环境 变量 
GIT_DIR 为 工作 区 指定 版 本 库 目录 ， 甚 至 还 要 指定 工作 区 目录 。 








Git 还 专门 提供 了 一 个 git grep 命 令 ， 这 样 在 工作 区 根 目 录 下 执行 查 








找 时 ， 目 录 .git 也 不 会 对 搜索 造成 影响 。 


关于 辅助 目录 的 详细 讨论 请 参见 本 书 第 2 篇 第 4.2 节 中 的 内 容 。 


2.5 重 写 提交 说 明 


很 多 人 可 能 像 我 一 样 ， 在 敲 下 回 车 之 后 才 发 现 提交 说 明 中 有 错 别 
字 ， 或 忘记 了 写 关 联 的 Bug ID， 此 时 就 需要 重 写 提交 说 明 。 


1.SVN 的 解决 方案 


在 默认 情况 下 ，SVN 的 提交 说 明 是 茶 止 更 改 的 ， 因 为 SVN 的 提交 说 
明 属 于 不 受 版 本 控制 的 属性 ， 一 旦 修改 就 不 可 恢复 。 我 建议 SVN 的 管理 
员 只 有 在 配置 了 版 本 库 更 改 的 外 发 邮件 通知 之 后 ， 再 开放 提交 说 明 更 改 
的 功能 。 我 发 布 于 SourceForge 上 的 pySvnManager 项 目 提供 了 SVN 版 本 
库 图 形 化 的 多 子 管理 ， 会 简化 管理 员 的 配置 工作 。 


即使 SVN 管 理 员 局 用 了 允许 更 改 提 交 说 明 的 设置 ， 修 改 提 交 说 明 也 
还 是 挺 复杂 的 ， 看 看 下 面 的 命令 : 





$ svn ps --revprop -r <REV> svn:1l0g "new 1og message..." 





2.Git 的 解决 方案 


Git 修 改 提交 说 明 很 简单 ， 而 且 提 交 说 明 的 修改 也 是 被 追踪 的 。Git 
修改 最 新 提交 的 提交 说 明 最 为 简单 ， 使 用 一 条 名 为 修补 提交 的 命令 即 
证 。 





$ git commit --amend 








这 个 命令 如 果 不 带 -m 参 数 ， 会 进入 提交 说 明 编辑 界面 ， 修 改 原来 的 
提交 说 明 ， 直 到 满意 为 止 。 


如 果 要 修改 某 个 历史 提交 的 提交 说 明 ，Git 也 可 以 实现 ， 但 要 用 到 
另外 一 个 命令 : 变 基 命 令 。 例 如 ， 要 修改 <commit-id> 所 标识 的 提交 的 
提交 说 明 ， 执 行 下 面 的 命令 ， 并 在 弹出 的 变 基 索引 文件 中 修改 相应 提交 
前 面 的 动作 的 关键 字 。 





$ git rebase -i <commit-id>^ 


关于 如 何 使 用 交互 式 变 基 操 作 更 改 历 史 提 交 的 提交 说 明 ， 请 参见 本 
书 第 2 篇 第 12 章 中 的 内 容 。 





2.6 ” 想 吃 后 悔 药 
假如 提交 的 数据 中 不 小 心包 含 了 一 个 不 应 该 检 入 的 虚拟 机 文件 一 一 
大 约 有 1 个 GB! 这 时 候 ， 您 会 多 么 希望 这 个 世界 上 有 后 悔 药 卖 啊 。 
1.SVN 的 解决 方案 


SVN 遇 到 这 个 问题 该 怎么 办 呢 ? 删除 错误 加 入 的 大 文件 后 再 提 区 ， 
这 样 的 操作 是 不 能 解决 问题 的 。 虽 然 表 面 上 去 掉 了 这 个 文件 ， 但 是 它 依 
然 存 在 于 历史 中 。 





管理 员 可 能 是 受 影响 最 大 的 人 ， 因 为 他 要 负责 管理 服务 器 的 磁盘 衬 
间 占 用 及 版 本 库 的 备份 。 实 际 上 这 个 问题 也 只 有 管理 员 才 能 解决 ， 所 以 
你 必须 加 管理 员 坦 白 ， 让 他 帮 你 在 服务 器 端 彻底 删除 错误 引入 的 大 文 
件 。 我 要 告诉 你 的 是 ， 对 于 管理 员 ， 这 并 不 是 一 个 简单 的 活 。 


(1) 如 果 SVN 管 理 员 没有 历史 备份 ， 只 能 重新 用 svnadmin dump 导 
出 整个 版 本 库 。 


(2) 再 用 svndumpfilter 命 令 过 小 挥 不 应 检 入 的 大 文件 。 
(3) 然后 用 svnadmin load 重 建 版 本 库 。 


上 面 的 操作 描述 中 省 略 了 一 些 和 守门， 如果 要 把 穷 门 讲 清楚 ， 这 本 书 





就 不 是 讲 Git， 而 是 讲 SVN 了 ， 故 本 书 中 不 进行 深入 探讨 。 


2.Git 的 解决 方案 





如 采 你 用 Git， 一 切 就 会 变 得 非常 简单 ， 而 且 你 也 不 必 去 乞求 管理 
因为 使 用 Git， 每 个 人 都 是 管理 员 。 


3 


如 果 是 最 新 的 提交 引入 了 不 该 提交 的 大 文件 ， winxp.img， 操 作 起 
来 会 非常 简单 ， 还 是 用 修补 提交 命令 。 





$ git rm --cached winxp.img 
$ git commit --amend 








如 果 是 历史 版 本 ， 例 如 是 在 <commit-id> 所 标识 的 提交 中 引入 的 文 
件 ， 则 需要 使 用 变 基 操作 。 





$ git rebase -i <commit-id>^ 








执行 交互 式 变 基 操 作 抛弃 历史 提交 ， 版 本 库 还 不 能 立即 瘦身 ， 具 体 
原因 和 解决 方案 请 参见 本 书 第 2 篇 第 14 章 中 的 内 容 。 除 了 使 用 变 基 操 
作 ，Git 还 有 更 多 的 武器 可 以 实现 版 本 库 的 整理 操作 ， 具 体 请 参见 本 书 
第 6 篇 第 35.4 节 的 内 容 。 








2.7 更 好 用 的 提交 列表 





正确 的 版 本 控制 系统 的 使 用 方法 是 ， 一 次 提交 只 干 一 件 事 : 或 是 完 
成 了 一 个 新 功能 ， 或 是 修改 了 一 个 Bug、 或 是 写 完 了 一 节 的 内 容 ， 或 是 
添加 了 一 幅 图 片 ， 残 执行 一 次 提交 。 不 要 在 下 班 时 才 想 起 来 要 提交 ， 那 
样 的 话 版 本 控制 系统 就 被 降格 为 文件 备份 系统 了 。 











但 有 时 在 同一 个 工作 区 中 可 能 要 同时 做 两 件 事情 : 一 个 是 尚未 完成 
的 新 功能 ， 另 外 一 个 是 解决 刚刚 发 现 的 Bug。 很 多 版 本 控制 系统 没有 提 
交 列 表 的 概念 ， 要 么 需要 在 命令 行 中 指定 要 提交 的 文件 ， 要 么 默认 把 所 
有 修改 内 容 全 部 提交 ， 破 坏 了 一 次 提交 只 干 一 件 事 的 原则 。 








1.SVN 的 解决 方案 


SVN 1.5 开 始 提 供 变 更 列表 (change list〉 的 功能 ， 是 通过 引入 一 个 
新 的 命令 svn changelist 来 实现 的 。 但 是 我 从 来 束 没 有 真正 用 过 ， 因 为 : 


" 定义 一 个 变更 列表 太 麻 烦 。 例 如 ， 没 有 一 个 快捷 命令 将 当前 所 有 
改动 的 文件 加 入 列表 ， 也 没有 快捷 命令 将 工作 区 中 的 新 文件 全 部 加 入 列 
表 。 


“一 个 文件 不 能 同时 属于 两 个 变更 列表 。 两 次 变更 不 许 有 文件 交 
又 ， 这 样 的 限制 不 合理 。 


` 变更 列表 是 一 次 性 的 ， 提 交 之 后 自动 消失 。 这 样 的 设计 没有 问 
题 ， 但 是 相 比 定 义 列表 时 的 繁琐 ， 以 及 提交 时 必须 指定 列表 的 繁琐 ， 使 
用 变更 列表 未 免得 不 偿 失 。 


` 因为 Subversion 的 提交 不 能 撤销 ， 如 果 在 提交 时 忘 了 提供 变更 列 
表 名 称 以 针对 特定 的 变更 列表 进行 提交 ， 错 误 的 提交 内 容 将 无 法 补救 。 


总 之 ，SVN 的 变更 列表 尚 不 如 鸡肋 ， 食 之 无 味 ， 弃 之 不 可 惜 。 


2.Git 的 解决 方案 








Git 通 过 提交 暂 存 区 实现 对 提交 内 容 的 定制 ， 非 第 完美 地 实现 了 对 
工作 区 的 修改 内 容 进行 得 选 提交 : 


: 执行 git add 命 令 将 修改 内 容 加 入 提交 暂 存 区 。 执 行 git add-u 命 令 可 
以 将 所 有 修改 过 的 文件 加 入 暂 存 区 ， 执 行 git add-A 命 令 可 以 将 本 地 删除 
文件 和 新 增 文 件 都 登记 到 提交 暂 存 区 ， 执 行 git add-p 命 令 甚至 可 以 对 一 
个 文件 内 的 修改 进行 有 选择 性 的 添加 。 


一 个 修改 后 的 文件 被 登记 到 提交 暂 存 区 后 ， 可 以 继续 修改 ， 继 续 
修改 的 内 容 不 会 被 提交 ， 除 非 对 此 文件 再 执行 一 次 git add 命 令 。 即 一 个 
修改 的 文件 可 以 拥有 两 个 版 本 ， 在 提交 暂 存 区 中 有 一 个 版 本 ， 在 工作 区 
中 有 另外 一 个 版 本 。 


` 执行 git commit 命 令 提 交 ， 无 须 设 定 变更 列表 ， 直 接 将 登记 在 暂 


存 区 中 的 内 容 提 交 。 


“Git 支持 撤销 提交 ， 而 且 可 以 撤销 任意 多 次 。 


只 要 使 用 Git， 就 会 时 刻 与 隐形 的 提交 列表 打交道 。 本 书 第 2 篇 第 5 


章 会 详细 介绍 Git 的 这 一 特性 ， 相 信 你 会 爱 上 Git 的 这 个 特性 。 


2.8 更 好 的 委 腊 比较 








Git 对 差异 比较 进行 了 扩展 ， 支 持 对 二 进 制 文件 的 差异 比较 ， 这 是 
对 GNU 的 diff 和 patch 命 令 的 重要 补充 。 而 且 Git 的 差异 比较 除了 文 持 基 于 
行 的 差异 比较 外 ， 还 支持 在 一 行内 逐 字 比 较 的 方式 ， 当 向 git diff 命 令 传 
递 --word-diff 参 数 时 ， 就 会 进行 逐 字 比较 。 








上 面 介绍 了 工作 区 的 文件 修改 可 能 会 有 两 个 不 同 的 版 本 : 一 个 在 提 
交 暂 存 区 ， 一 个 在 工作 区 。 因 此 ， 在 执行 git diff 命 令 时 会 遇 到 令 Git 新 手 
费解 的 现象 。 


` 修改 后 的 文件 在 执行 git diff 命 令 时 会 看 到 修改 造成 的 差异 。 


“ 修改 后 的 文件 通过 git add 命 令 提 交 到 暂 存 区 后 ， 再 执行 git diff 命 
令 将 看 不 到 该 文件 的 差异 。 


` 继续 对 此 文件 进行 修改 ， 再 次 执行 git diff 命 令 会 看 到 新 的 修改 显 


示 在 差异 中 ， 而 看 不 到 旧 的 修改 。 


. 执行 git diff--cached 命 令 才 可 以 看 到 添加 到 暂 存 区 中 的 文件 所 做 出 
的 修改 。 


Git 差 异 比较 的 命令 充满 了 魔法 ， 本 书 第 5.3 节 会 融 您 破解 Git 的 diff 





旦 您 习惯 了 ， 就 会 非常 喜欢 git diff 的 这 个 行为 。 


2.9 工人 月 直 度 你 存 





如 果 在 工作 区 的 修改 尚未 完成 时 忽然 有 一 个 紧急 的 任务 ， 需 要 从 一 
个 干净 的 工作 区 开始 新 的 工作 ， 或 要 切换 到 别 的 分 文 进行 工作 ， 那 么 如 
何 保存 当前 尚未 完成 的 工作 进度 呢 ? 





1.SVN 的 解决 方案 





如 果 版 本 库 规模 不 大 ， 最 好 重新 检 出 一 个 新 的 工作 区 ， 在 新 的 工作 
区 进行 工作 。 人 否则 ， 可 以 执行 下 面 的 操作 。 
$ svn diff > /path/to/saved/patch.file 


$ svn revert -R 
$ svn switch <new_branch> 








在 新 的 分 文中 工作 完毕 后 ， 再 切换 回 当前 分 文 ， 将 补丁 文件 重新 应 
用 到 工作 区 。 


$ svn Switch <original_branch> 
$ patch -p1 < /path/to/saved/patch.file 





但 是 切记 SVN 的 补丁 文件 不 支持 二 进 制 文件 ， 这 种 操作 方法 可 能 会 
于 天 对 三 进 市 文件 的 更 改 ! 


2.Git 的 解决 方案 


Git 提 供 了 一 个 可 以 保存 和 恢复 工作 进度 的 命令 git stash。 这 个 命令 
非常 方便 地 解决 了 这 个 难题 。 


在 切换 到 新 的 工作 分 支 之 前 执行 git stash 保 存 工 作 进 度 ， 工 作 区 就 
会 变 得 非常 干净 ， 然 后 就 可 以 切换 到 新 的 分 文中 了 。 





$ git stash 
$ git checkout <new_branch> 





新 的 工作 分 文 修改 完毕 后 ， 再 切换 回 当前 分 文 ， 调 用 git stash pop 命 
令 则 可 恢复 之 前 保存 的 工作 进度 。 








$ git checkout <orignal_branch> 
$ git stash pop 








本 书 第 2 篇 第 9 章 会 为 您 揭 开 git stash 命 令 的 奥秘 。 


2.10 ”代理 SVN 提 交 实 现 移动 式 办 公 


使 用 像 SVN 一 样 的 集中 式 版 本 控制 系统 ， 要 求 使 用 者 和 版 本 控制 服 
务 吉 之 间 要 有 网 络 连接 ， 如 果 因 为 出 差 在 外 或 在 家 办 公 访 问 不 到 版 本 控 
制服 务 嚣 束 无 法 提交 。Git 属 于 分 布 式 版 本 控制 系统 ， 不 存在 这 样 的 问 


匮 。 








当 版 本 控制 服务 器 无 法 实现 从 SVN 到 Git 的 迁移 时 ， 仍 然 可 以 使 用 
Git 进 行 工 作 。 在 这 种 情况 下 ，Git 作 为 客户 端 来 操作 SVN 服 务 器 ， 实 现 
在 移动 办 公 状 态 下 的 版 本 提交 《当然 是 在 本 地 Git 库 中 提交 ) 。 当 能 够 
连通 SVN 服 务 器 时 ， 一 次 性 将 移动 办 公 状 态 下 的 本 地 提交 同步 到 SVN 服 
务 器 。 整 个 过 程 对 于 SVN 来 说 是 透明 的 ， 没 有 人 知道 你 是 使 用 Git 在 进 


行 提交 。 


使 用 Git 来 操作 SVN 版 本 控制 服务 器 的 一 般 工 作 流程 为 : 


(1) 访问 SVN 服 务 右 ， 将 SVN 版 本 库 克 隆 为 一 个 本 地 的 Git 库 ， 一 
个 货真价实 的 Git 库 ， 不 过 其 中 包含 针对 SVN 的 扩展 。 





$ git svn clone <svn_repos_url> 





(2) 使 用 Git 命 令 操 作 本 地 克隆 的 版 本 库 ， 例 如 提交 束 使 用 git 


commit 命 令 。 


《3) 当 能 够 通过 网 络 连接 到 SVN 服 务 器 ， 并 想 将 本 地 提交 同步 到 
SVN 服 务 器 时 ， 先 获取 SVN 服 务 器 上 最 新 的 提交 ， 然 后 执行 变 基 操 作 ， 
最 后 再 将 本 地 提交 推送 给 SVN 服 务 器 。 





$ git svn fetch 
$ git svn rebase 
$ git svn dcommit 








本 书 第 4 篇 第 26 章 会 详细 介绍 这 一 话题 。 


2.11 无 处 不 在 的 分 页 器 


虽然 拥有 图 形 化 的 客户 端 ， 但 Git 的 主要 操作 还 是 以 命令 行 的 方式 
完成 的 。 使 用 命令 行 方式 的 好 处 一 个 是 快 ， 为 外 一 个 是 可 以 防止 妃 标 手 
的 出 现 。Git 的 命令 行 加 入 了 大 量 的 人 性 化 设计 ， 包 括 命令 补 全 、 彩 
字符 输出 中 等 ， 不 过 最 具 特 色 的 还 是 无 处 不 在 的 分 页 器 。 


在 操作 其 他 版 本 控制 系统 的 命令 行 时 ， 如 来 命令 的 输出 超过 了 一 
屏 ， 为 了 能 够 逐 屏 显示 ， 需 要 在 命令 的 后 面 加 上 一 个 管道 符号 将 输出 区 


给 一 个 分 页 器 。 例 如 : 











$ svn 10g | less 











而 Git 则 不 用 如 此 麻烦 ， 因 为 每 个 Git 命 令 自 动 带 有 一 个 分 页 器 ， 默 
认 使 用 less 命 令 (ess-FRSX) 进行 分 页 。 当 一 屏 显示 不 下 时 局 动 分 页 
器 ， 这 个 分 页 器 文 持 市 颜色 的 字符 输出 ， 对 于 太 长 的 行 则 采用 截断 方式 
处 理 。 因 为 less 分 页 器 在 翻 屏 时 使 用 了 vi 风格 的 热 键 ， 如 果 您 不 熟悉 vi 的 
话 ， 可 能 会 遇 到 麻烦 。 下 面 是 分 页 占 中 常用 的 热 键 : 





` 按 空 格 下 翻 一 页 ， 按 字母 bp 上 翻 一 页 。 
字母 d 和 u: 分 别 代 表 向 下 翻动 半 页 和 向 上 翻动 半 页 。 
` 字母 j 和 k: 分 别 代 表 向 上 翻 一 行 和 向 下 翻 一 行 。 


.如果 行 太 长 被 截断 ， 可 以 用 左 箭头 和 右 箭 头 使 窗口 内 容 左 右 深 


` 输入 /pattern: 向 下 寻找 和 pattetn 匹 配 的 内 容 。 
` 输入 ?pattern: 向 上 寻找 和 pattetn 匹 配 的 内 容 。 
.字母 n 或 N: 代表 向 前 或 向 后 继续 寻找 。 


" 字母 g: 跳 到 第 一 行 ; 字母 G: 跳 到 最 后 一 
母 g: 则 跳 转 到 对 应 的 行 。 


mY 
E> 
> 
党 
书 
并 
这 
3 

中 


` 输入 ! : 可 以 执行 Shell 命 令 。 





如 果 不 习 惯 分 页 器 的 长 行 截断 模式 而 希望 能 够 自动 换行 ， 可 以 通过 
设置 LESS 环 境 变量 来 实现 。LESS 环 境 变量 设置 如 下 : 





$ export LESS=FRX 








或 者 使 用 Git 的 方式 ， 通 过 定义 Git 配 置 变 量 来 改变 分 页 器 的 默认 行 





为 。 例 如 设置 core.pager 配 置 变量 如 下 : 





$ git config --global core.pager 'less -+$LESS -FRX' 





[1] 须 通 过 Git 配 置 变 量 启 用 ， 如 运行 命令 : git config --global color.ui true 


2.12 快 


您 有 项 目 托 管 在 sourceforge.net 的 CVS 或 SVN 服 务 器 上 么 ? 是否 会 因 
为 公司 的 SVN 服 务 嚣 部署 在 男 外 一 个 城市 而 逢 要 经 过 互联 网 才能 访问 ? 





使 用 传统 的 集中 式 厂 本 控制 服务 器 时 ， 如 采 遇 到 上 面 的 情况 ， 而 且 
网 络 市 宽 没 有 保证 ， 那 么 使 用 起 来 时 一 定 会 因为 速度 慢 而 让 人 痛 知 不 
堪 。Git 作 为 分 布 式 版 本 控制 系统 彻底 解决 了 这 个 问题 ， 几 乎 所 有 的 操 
作 都 在 本 地 进行 ， 而 且 速 度 还 不 是 一 般 的 快 。 


还 有 很 多 其 他 的 分 布 式 版 本 控制 系统 ， 如 Hg 和 Bazaar 等 ， 与 这 些 分 
布 式 版 本 控制 系统 相 比 ，Git 在 速度 上 也 有 优势 ， 这 得 益 于 Git 独 特 的 版 
本 库 设计 。 第 2 篇 的 相关 章节 会 同 您 展示 Git 独 特 的 版 本 库 设 计 。 











其 他 很 多 的 版 本 控制 系统 ， 当 输入 检 出 、 更 新 或 元 隆 等 命令 后 ， 只 
能 双手 合十 ， 然 后 望 眼 欲 军 ， 因 为 整个 操作 过 程 不 知道 什么 时 候 才 能 够 
完成 。 而 Git 在 版 本 库 殉 隆 及 与 版 本 库 同步 的 时 候 ， 能 够 实时 地 显示 完 
成 的 进度 ， 这 不 但 是 非常 人 性 化 的 设计 ， 更 体现 了 Git 的 智能 。Git 的 智 
能 协议 源 目 于 会 话 过 程 中 在 客户 端 和 服务 器 端 各 目 局 用 了 一 个 会 话 的 角 
色 ， 用 于 按 需 传输 和 获取 进度 。 


第 3 章 ”Git 的 安装 和 使 用 


Git 源 目 Linux， 现 在 已 经 可 以 部 署 在 所 有 的 主流 平台 之 上 ， 包 括 
Linux、Mac OS X 和 Windows。 我 们 在 开始 Git 之 旅 之 前 ， 首 先 要 做 的 就 


是 安装 Git。 





3.1 在 Linux 下 安装 和 使 用 Git 


Git 延 生 于 Linux 平 台 并 作为 版 本 控制 系统 率先 服务 于 Linux 内 核 ， 
此 在 Linux 上 安装 Git 是 非常 方便 的 。 可 以 通过 两 种 不 同 的 方式 在 Linux 上 
安装 Git: 一 种 方法 是 通过 Linux 友 行 版 的 包 管理 器 安 疲 已 经 编译 好 的 二 
进 制 格式 的 Git 软 件 包 ， 夯 外 一 种 方式 束 是 从 Git 源 码 开 始 安装 。 








3.1.1 所 管理 器 方式 安装 


用 Linux 发 行 版 的 包 管 理 器 安装 Git 最 为 简单 ， 而 且 会 自动 配置 好 命 
令 补 齐 等 功能 ， 但 安装 的 Git 可 能 不 是 最 新 的 版 本 。 还 有 一 点 要 注意 ， 
Git 软 件 包 在 有 的 Linux 发 行 版 中 可 能 不 叫 git， 而 叫 git-core。 这 是 因为 有 
一 款 名 为 GNU 交 互 工具 1 (GNU Interactive Tools) 的 GNU 软 件 ， 在 Git 
之 前 就 在 一 些 Linux 发 行 版 (Deian lenny) 中 占用 了 git 这 个 名 称 。 为 了 
以 示 区 分 ， 作 为 版 本 控制 系统 的 Git， 其 软件 包 在 这 些 平台 就 被 命名 为 
git-core。 不 过 ， 因 为 作为 版 本 控制 系统 的 Git 太 有 名 了 ， 所 以 一 些 Linux 
发 行 版 在 最 新 的 版 本 中 将 GNU Interactive Tools 软 件 包 的 名 称 由 git 改 为 
了 gnuit， 将 git-core 改 为 了 git。 因 此 在 下 面 介 绍 的 在 不 同 的 Linux 发 行 版 
中 安装 Git 时 ， 会 看 到 有 git 和 git-core 两 个 不 同 的 名 称 。 




















Ubuntu 10.10 (maverick) 或 更 新 的 版 本 、Debian (squeeze) 或 更 


新 的 版 本 : 





$ sudo aptitude install git 
$ sudo aptitude install git-doc git-svn git-email git-gui gitk 





其 中 git 软 件 包 包含 了 大 部 分 Git 命 令 ， 是 必 装 的 软件 包 。 


软件 包 git-svn、git-email、git-gui、gitk 本 来 也 是 Git 软 件 包 的 一 部 
分 ， 但 是 因为 有 关 不 一 样 的 软件 包 依 赖 〈( 如 更 多 的 perl 模 组 和 k 等 〉， 
所 以 单独 作为 软件 包 发 布 。 


软件 包 git-doc 则 包含 了 Git 的 HTML 格 式 文档 ， 可 以 选择 安装 。 如 果 
安装 了 Git 的 HTML 格 式 的 文档 ， 则 可 以 通过 执行 git help-w<sub- 
command> 命 令 来 自动 用 Web 浏 览 器 打开 相关 子 命令 <sub-command> 的 
HTML 帮 助 。 


.Ubuntu 10.04 (lucid) 或 更 老 的 版 本 、Debian (lenny) 或 更 老 的 版 


在 老 版 本 的 Debian 中 ， 软 件 包 git 实 际 上 是 指 GNU Interactive Tools， 
而 非 作 为 版 本 控制 系统 的 Git。 作 为 版 本 控制 系统 的 Git 在 软件 包 gitrcore 
中 。 





$ sudo aptitude install git-core 
$ sudo aptitude install git-doc git-svn git-email git-gui gitk 





.RHEL、Fedotfa、 CentOS: 





$ yum install git 
$ yum install git-svn git-email git-gui gitk 





在 其 他 发 行 版 中 安装 Git 的 过 程 和 上 面 介绍 的 方法 类 似 。Git 软 件 包 
在 这 些 发 行 版 里 或 称 为 git， 或 称 为 git-core。 


3.1.2 ”从 源 代码 进行 安装 


访问 Git 的 官方 网 站 : http://git-scm.com/ 。 下 载 Git 源 码 包 ， 例 如 : 
git-1.7.4.1.tar.bz2 2 。 安 装 过 程 如 下 : 


(1) 展开 源码 包 ， 并 进入 到 相应 的 目录 中 。 





$ tar -jxvf git-1.7.4.1.tar.bz2 
$ cd git-1.7.4.1/ 








(2) 安装 方法 写 在 INSTALL 文 件 中 ， 参 照 其 中 的 指示 即 可 完成 安 
装 。 下 面 的 命令 将 Git 安 装 在 /usr/local/bin 中 。 





$ make prefix=/usr/local all 
$ sudo make prefix=/usr/local install 





(3) 安装 Git 文 档 (可 选 )。 


编译 的 文档 主要 是 HTML 格 式 的 文档 ， 方 便 通 过 git help-w<sub- 


command> 命 令 查 看 。 实 际 上 ， 即 使 不 安装 Git 文 档 ， 也 可 以 使 用 man 手 
册 查 看 Git 帮 助 ， 使 用 命令 git help<sub-command> 或 git<sub-command>-- 
help 即 可 。 


编译 文档 依赖 asciidoc， 因 此 需要 先 安装 asciidoc〈 如 果 疝 未 安装 的 
话 ) ， 然 后 编译 文档 。 在 编译 文档 时 要 花费 很 多 时 间 ， 要 有 耐心。 








$ make prefix=/usr/local doc info 
$ sudo make prefix=/usr/local install-doc install-html] install-info 





安装 完毕 之 后 ， 就 可 以 在 /usr/local/bin 下 找到 git 命 令 。 


3.1.3” 从 Git 版 本 库 进行 安装 


如 宁 在 本 地 死 隆 一 个 Git 项 目的 版 本 库 ， 就 可 以 用 版 本 库 同步 的 方 
式 获取 最 新 版 本 的 Git， 这 样 在 下 载 不 同 版 本 的 Git 源 代码 时 实际 上 采用 
了 增 量 方式 ， 非 常 节省 时 间 和 和 空间。 当然 使 用 这 种 方法 的 前 提 是 已 经 用 
其 他 方法 安装 好 了 Git， 具 体操 作 过 程 如 下 。 





(1) 元 隆 Git 项 目的 版 本 库 到 本 地 。 





$ git clone git://git.kernel.org/pub/scm/git/git.git 
$ cd git 








2) 如 果 本 地 已 经 克隆 过 一 个 Git 项 目的 版 本 库 ， 直 接 在 工作 区 中 


更 新 ， 以 获得 最 新 版 本 的 Git。 





$ git fetch 





(3) 执行 清理 工作 ， 避 免 前 一 次 编译 的 遗留 文件 对 编译 造成 影 
啊 。 注 意 ， 下 面 的 操作 将 丢 莽 本 地 对 Git 代 码 的 改动 。 








$ git clean -fdx 
$ git reset --hard 





(4) 查看 Git 的 里 程 碑 ， 选 择 最 新 的 版 本 进行 安装 ， 例 如 v1.7.4.1。 





$ git tag 


V1.7.4.1 





(5) 检 出 该 版 本 的 代码 。 





$ git checkout v1.7.4.1 





(6) 执行 安装 。 例 如 ， 安 装 到 /usr/local 目 录 下 。 





$ make prefix=/usr/local all doc info 
$ sudo make prefix=/usr/local install \ 
install-doc install-html install-info 








我 在 撰写 本 书 的 过 程 中 ， 就 是 通过 Git 版 本 库 的 方式 安装 的 ， 
在 /opt/git 目 录 下 安装 了 多 个 不 同 版 本 的 Git， 以 测试 Git 的 兼容 性 。 可 以 
使 用 类 似 下 面 的 脚本 来 批量 安装 不 同 版 本 的 Git。 


1 


#!/bin/sh 

for ver in \ 

V1.5.0 N 
\ 
\ 


echo "Begin install Git $ver.",; 
git reset --hard 
git clean -fdx 
git checkout $ver || { 
echo "Checkout git $ver failed."; exit 1 


} 

make prefix=/opt/git/$ver all && \ 

sudo make prefix=/opt/git/$ver install || { 
echo "Install git $ver failed."; exit 1 


} 
echo "Installed Git $ver." 
done 





3.1.4 ”命令 补 齐 


Linux 的 Shell 环 境 (bash)〉 通过 bash-completion 软 件 包 提供 命令 补 齐 
功能 ， 在 录入 命令 参数 时 按 一 次 或 两 次 TAB 键 可 实现 参数 的 自动 补 齐 或 
提示 。 例 如 输入 git com 后 按 下 TAB 键 ， 会 自动 补 齐 为 git commit。 





如 果 通 过 包 管 理 器 方式 安装 Git， 一 般 都 已 经 为 Git 配 置 好 了 自动 补 
齐 ， 但 是 如 果 是 以 源码 编译 的 方式 安装 Git， 就 需要 为 命令 补 齐 多 做 些 
工作 ;具体 操作 过 程 如 下 。 


(1) 将 Git 源 码 包 中 的 命令 补 齐 脚本 复制 到 bash-completion 对 应 的 
目录 中 。 





$ cp contrib/completion/git-completion.bash \ 
/etc/bash_completion.d/ 





(2) 重新 加 载 上 自动 补 齐 脚本 ， 使 之 在 当前 的 shell 中 生效 。 


$ . /etc/bash_completion 


(3) 为 了 能 够 在 终端 开启 时 目 动 加 载 bash_completion 脚 本 ， 需 要 
在 系统 配置 文件 /etc/profile 5] 及 本 地 配置 文件 ~/bashrc 四 中 添加 下 面 的 


内 容 。 





if [ -f /etc/bash completion ]; then 
, /etc/bash_completion 
fi 


3.1.5” ”中文 支持 


Git 的 本 地 化 做 得 并 不 完善 ， 命 令 的 输出 及 命令 的 帮助 还 只 能 输出 
英文 ， 也 许 在 未 来 的 版 本 中 会 使 用 gettext 实 现 本 地 化 ， 就 像 目 前 对 git- 
gui 命 令 所 做 的 那样 。 





中 文 用 户 最 关心 的 问题 还 有 : 是 否 可 以 在 提交 说 明 中 使 用 中 文 ? 是 
个 可 以 使 用 中 文 文件 名 或 目录 名 ? 是 否 可 以 使 用 中 文 来 命名 分 支 或 里 程 
碑 ? 简单 地 说 ， 可 以 在 提交 说 明 中 使 用 中 文 ， 但 是 需要 对 Git 进 行 设 
置 。 至 于 用 中 文 来 命名 文件 、 目 录 和 引用 ， 只 有 在 使 用 UTF-8 字 符 集 的 
环境 下 (Linux、Mac OS X、Windows 下 的 Cygwin) 才 可 以 ， 否 则 应 尽 
量 避 免 使 用 。 











1.UTF-8 字 符 集 


Linux 平 台 的 中 文 用 户 一 般 会 使 用 UTF-8 字 符 集 ，Git 在 UTF-8 字 符 集 
下 可 以 工作 得 非常 好 : 


` 在 提交 时 ， 可 以 在 提交 说 明 中 输入 中 文 。 
显示 提交 历史 ， 能 够 正常 显示 提交 说 明 中 的 中 文字 符 。 


. 可 以 添加 名 称 为 中 文 的 文件 ， 并 可 以 在 同样 使 用 UTF-8 字 符 集 的 
Linux 环 境 中 克隆 和 检 出 。 


. 可 以 创建 带 有 中 文字 符 的 里 程 碑 名 称 。 


但 是 ， 在 默认 设置 下 ， 中 文 文件 名 在 工作 区 状态 输出 、 碍 看 历史 更 
改 概要 ， 以 及 在 补丁 文件 中 ， 文 件 名 中 的 中 文 不 能 正确 地 显示 ， 而 是 显 
示 为 八进制 的 字符 编码 ， 如 下 : 











$ git Status -S 

?7 "\350\257\264\346\230\216.txt" 

$ printf "\350\257\264\346\230\216.txt\n" 
说 明 .txt 





通过 将 Git 配 置 变 量 core.quotepath 设 置 为 false， 束 可 以 解决 中 文 文件 
名 在 这 些 Git 命 令 输出 中 的 显示 问题 。 





$ git config --global core.quotepath false 
$ git status -s 
?3 说 明 .txt 





2.GBK 字 符 集 


如 果 Linux 平 台 采 用 非 UTF-8 的 字符 集 ， 例 如 ， 用 zh_CN.GBK 字 符 
集 编码 (有 人 这 么 做 吗 ?”) ， 就 要 另外 再 做 些 工 作 了 。 


. 将 显示 提交 说 明 所 使 用 的 字符 集 设置 为 gbk， 这 样 使 用 gitlog 查 看 
提交 说 明 时 才能 够 正确 显示 其 中 的 中 文 。 





$ git config --global ii8n.logOutputEncoding gbk 





` 设置 录入 提交 说 明 时 所 使 用 的 字符 集 ， 以 便 在 commit 对 象 中 正确 


标注 字符 集 。 


Git 在 提交 时 并 不 会 对 提交 说 明 进行 从 GBK 字 符 集 到 UTF-8 的 转换 ， 
但 是 可 以 在 提交 说 明 中 标注 所 使 用 的 字符 集 ， 因 此 在 非 UTF-8 字 符 集 的 
平台 中 录入 中 文 时 需要 用 下 面 的 指令 设置 录入 提交 说 明 的 字符 集 ， 以 便 
在 commit 对 象 中 嵌入 正确 的 编码 说 明 。 














$ git config --global ii8n.commitEncoding gbk 





[1] http:/ /www.enu.org/software/ gnuit/ 

2 在 你 下 载 的 时 候 可 能 已 经 有 了 更 新 的 版 本 。 

[3] 配置 文件 /etc/profile 及 ~/.bash_profile、~/.profile 等 作用 于 交互 式 登 录 
shell。 


四 配置 文件 ~/.bashtc 作 用 于 交互 式 非 登 录 shell， 如 scteen 或 byobu 中 建立 


的 新 的 shell 窗 口 。 


3.2 ”在 Mac OS X 下 安装 和 使 用 Git 


Mac OS X 被 称 为 最 人 性 化 的 操作 系统 之 一 ， 工 作 在 Mac 上 是 件 非常 
尾 意 的 事情 ， 工 作 中 又 怎 能 没有 Git 呢 ? 





3.2.1 以 二 进 制 发 布 包 的 方式 安装 


Git 在 Mac OS X 中 也 有 好 几 种 安装 方法 。 最 简单 的 方式 是 安装 .dmg 
格式 的 安装 包 。 


访问 git-osx-installer 的 官方 网 站 : http://code.google.com/p/git-osx- 
installer/ ， 下 载 Git 安 装 包 。 安 装 包 带 有 .dmg 扩 展 名 ， 是 苹果 人 厂 盘 镜 像 
(Apple Disk Image) 格式 的 软件 发 布 包 。 从 官方 网 站 上 下 载 文件 名 格 

式 为 git-<version>-<arch>-leopard.dmg 的 安装 包 文 件 ， 例 如 : git-1.7.4- 








X86_64-leopard.dmg 是 64 位 的 安装 包 ，git-1.7.4-i386-leopard.dmg 是 32 位 
的 安装 包 。 建 议 选择 64 位 的 软件 包 ， 因 为 Mac OS X10.6《〈 和 雪豹 ) 完美 
地 兼容 32 位 和 64 位 《开机 按 住 键 租 数 字 3 和 2 进入 32 位 系统 ， 按 住 6 和 4 进 
入 64 位 系统 ) ， 即 使 内 核 的 架构 是 32 位 的 ， 也 可 以 放心 地 运行 64 位 的 软 
件 包 。 





苹果 的 .dmg 格 式 的 软件 包 实 际 上 是 一 个 磁盘 上 映像， 安装 起 来 非常 方 
便 ， 点 击 该 文件 就 可 以 直接 挂 载 到 Finder 中 ， 打 开 后 如 图 3-1 所 示 。 





了 设备 
允 Mac os 
El iDisk 
gooTCAMP 
局 Git 1.7.3.5 i386 Leopard 


git-1.7.3.5-x86_64- README.txt 
leopard.pkg 


| 


- 


| SHELL 


setup git PATH for non- uninstall.sh 
‘a | terminal programs.sh 
v 





图 3-1 在 Mac OS X 下 打开 .dmg 格 式 磁 盘 镜 像 


图 3-1 中 显示 为 拆 包 图 标的 文件 “扩展 名 为 .pkg) 就 是 Git 的 安装 程 
序 ， 男 外 的 两 个 脚本 程序 ， 一 个 用 于 应 用 的 季 载 (uninstall.sh〉， 男 外 
一 个 带 有 长 文件 名 的 脚本 在 Git 安 装 后 再 执行 ， 为 非 终端 应 用 注册 Git 的 
安 疼 路 径 ， 这 是 因为 Git 部 车 在 标准 的 系统 路 径 之 外 /uslocal/giVbin。 


点 击 扩展 名 为 .pkg 的 安装 程序 ， 开 始 Git 的 安装 〈 以 安装 Git1.7.3.5 版 
本 为 例 ) ， 根 据 提示 按 步 又 完成 安装 ， 如 图 3-2 所 示 。 


欢迎 使 用 "Git 1.7.3.5 x86_64” 安 装 器 





安装 器 将 引导 您 完成 安装 此 软件 所 需要 的 步 屋 。 


。 安 关 类 型 必 a, 


大 元 ~ :十 








图 3-2 ”在 Mac OS X 下 安装 Git 


安装 完毕 后 ，Git 会 被 安装 到 /usr/local/git/bin/ 目 录 下 。 重 启 终 端 程 
序 ， 这 样 /etc/paths.d/git 文 件 为 PATH 环 境 变 量 中 添加 的 新 路 径 注 册 才 能 
生效 ， 然 后 就 可 以 在 终端 直接 运行 git 命 令 了 。 





3.2.2 ”安装 Xcode 


Mac OS X 基 于 Unix 内 核 开 发 ， 因 此 也 可 以 很 方便 地 通过 源码 编译 
的 方式 进行 安装 ， 但 是 默认 安装 的 Mac OS X 缺 乏 相应 的 开发 工具 ， 需 





要 安装 苹果 提供 的 Xcode 软件 包 。 在 Mac 随 机 附送 的 光盘 (Mac OS X 
Install DVD) 的 可 选 安装 文件 夹 下 就 有 Xcode 的 安装 包 〈 如 图 3-3 上 所 
示 ) ， 通 过 随机 光盘 安装 Xcode 可 以 省 去 网 络 下 载 的 麻烦 ， 要 知道 
Xcode 的 大 小 在 3GB 以 上 。 





从 中 从 (2) Mac OS X Install DVD ES 
次 选择 了 1 项 ( 共 4 项 ) ，83.9 MB 可 用 em 人 = 


级. 和 


安装 Mac OS X 





量 


DVD or CD Sharing Setup 





ss 
从 所 个 回 可 选 安装 3 
| 交 3 项 ，83.9 MB 可 用 一 人 | 
PDF 
About Xcode Xcode Optional Installs 


图 3-3 ”在 Mac OS 又 下 安装 Xcode 


3.2.3 ”使 用 Homebrew 安 装 Git 


Mac OS X 有 好 几 个 包 管 理 器 ， 用 于 管理 一 些 开源 软件 在 Mac OS X 
上 的 安装 和 升级 。 有 传统 的 MacPorts 1 、Fink 2l ， 还 有 更 为 简单 易 用 的 
Homebrew 6l 。 下 面 就 介绍 一 下 如 何 通过 Homebrew 包 管理 器 来 以 源码 包 
编译 的 方式 安装 Git。 





Homebrew 用 Ruby 语 言 开发 ， 文 持 干 余 种 开源 软件 在 Mac OS X 中 的 
部 署 和 管理 。Homebrew 项 目 托管 在 Github 上 ， 网 址 


为 : https://github.com/mxcl/homebrew 。 


首先 是 安装 Homebrew， 执 行 下 面 的 命令 : 





$ _ ruby -e \ 
"$(curl -fsSL https://gist.github.com/raw/323731/install_homebrew.rb)" 








安装 完成 后 ，Homebrew 的 主 程序 安装 在 /aswlocalbin/brew 中 ， 在 目 
录 /usr/local/Library/Formula/ 下 保存 了 Homebrew 支 持 的 所 有 软件 的 安装 
19| 直 。 


执行 下 面 的 命令 ， 通 过 Homebrew 安 装 Git。 





$ brew install git 





使 用 Homebrew 方 式 安装 ，Git 被 安装 在 /usr/local/Cellar/git/<version>/ 








中 ， 可 执行 程序 自动 在 /usr/local/bin 目 录 下 创建 符号 连接 ， 可 以 直接 在 
终端 程序 中 访问 。 


通过 brew list 命 令 可 以 查看 安装 的 开源 软件 包 。 





$ brew list 
git 





也 可 以 查看 东 个 软件 包 安 装 的 详细 路 径 和 安装 内 容 。 





$ brew list git 
/usr/local/Cellar/git/1.7.4.1/bin/gitk 





3.2.4 ”从 Git 源 码 进行 安装 





如 果 需 要 安装 历史 版 本 的 Git 或 是 尚 在 开发 中 的 未 发 布 版 本 的 Git， 
就 需要 从 源码 安装 或 通过 克隆 Git 源 码 库 的 方式 进行 安装 。 既 然 
Homebrew 就 是 通过 源码 编译 方式 安装 Git 的 ， 那 么 也 应 该 可 以 直接 从 源 
码 进行 安装 ， 但 是 使 用 Homebrew 安 装 Git 和 直接 通过 Git 源 码 安装 并 不 完 
全 等 同 ， 例 如 Homebrew 安 装 Git 文 档 是 通过 下 载 己 经 编译 好 的 Git 文 档 包 
进行 安装 ， 而 非 从 头 对 文档 进行 编译 。 














直接 通过 谣 码 安装 Git 软 件 及 文档 ， 遇 到 的 主要 问题 就 是 对 文档 的 
编译 ， 因 为 Xcode 没有 提供 Git 文 档 编 译 所 需要 的 相关 工具 。 但 是 ， 这 些 
工具 可 以 通过 Homebrew 进 行 安装 。 安 装 工 具 软 件 的 过 程 可 能 会 遇 到 一 


些小 麻烦 ， 不 过 大 多 可 以 通过 参考 命令 输出 予以 解决 。 





$ brew install asciidoc 
$ brew install docbook2x 
$ brew install xmlto 








当 编 译 源码 及 文档 的 工具 部 署 完成 后 ， 就 可 以 通过 源码 编译 Git。 





$ make prefix=/usr/local all doc info 
$ sudo make prefix=/usr/local install \ 
install-doc instal1-htm]l install-info 





3.2.5 ”命令 补 齐 


Va 


Git 通 过 bash-completion 软 件 包 实 现 命 令 自 动 补 齐 ， 在 Mac OS X 下 
可 以 通过 Homebrew 进 行 安 装 。 








$ brew search completion 
bash-completion 
$ brew install bash-completion 


Add the following lines to your ~/.bash_ profile file: 
if [ -f 'brew --prefix'/etc/bash completion ]; then 

， 'brew --prefix'/etc/bash_completion 
fi 








根据 bash-completion 在 安装 过 程 中 的 提示 ， 修 改 配置 文件 
~/.bash_profile 和 ~/.bashrc， 并 在 其 中 加 入 如 下 内 容 ， 以 便 在 终端 加 载 时 
自动 启用 命令 补 齐 。 





if [ -f ‘brew --prefix /etc/bash completion ]; then 
‘brew --prefix /etc/bash completion 





将 Git 的 命令 补 齐 脚本 拷贝 到 bash-completion 对 应 的 目录 中 。 





$ cp contrib/completion/git-completion.bash \ 
‘brew --prefix /etc/bash completion.d/ 











不 用 重启 终端 程序 ， 只 需要 运行 下 面 的 命令 即 可 立即 在 当前 的 shell 
中 加 载 命 令 补 齐 。 





$. ‘brew --prefix /etc/bash completion 





3.2.6 ”其 他 辅助 工具 的 安装 


本 书 中 还 会 用 到 一 些 常 用 的 GNU 或 其 他 开源 软件 ， 在 Mac OS X 下 
也 可 以 通过 Homebrew 进 行 安 装 。 这 些 软件 包括 : 


` gnupg: 数字 签名 和 加 密 工具 ， 在 为 Git 版 本 库 建立 签名 里 程 碑 时 
会 用 到 。 


. md5shalsum: 生成 MD5 或 SHA1 摘 要 ， 在 研究 Git 版 本 库 中 的 对 象 
时 会 用 到 。 


cvs2svn: CVS 版 本 库 迁 移 到 SVN 或 Git 的 工具 ， 在 版 本 库 迁 移 时 会 
用 到 o 


' stgit: Git 的 补丁 和 提交 管理 工具 。 
` quilt: 一 种 补丁 管理 工具 ， 在 介绍 StGit 时 会 用 到 。 


在 Mac OS X 下 能 够 使 用 到 的 Git 图 形 工 具 除 了 Git 软 件 包 自 带 的 gitk 
和 git gui 之 外 ， 还 有 GitX。 下 载 地 址 为 : 


" GitX 的 原始 版 本 : http://gitx.frim.nl/ 。 


* GitX 的 一 个 分 支 版 本 ， 提 供 增 强 的 功 
能 : https://github.com/brotherbard/gitx/downloads 。 


Git 的 图 形 工具 一 般 雷 要 在 本 地 克隆 版 本 库 的 工作 区 中 执行 ， 为 了 
能 与 Mac OS X 更 好 地 整合 ， 可 以 通过 插件 实现 与 Finder 的 整合 。 在 git- 
osx-installer 的 官方 网 站 : http://code.google.com/p/git-osx-installer/ 上 有 两 
个 以 OpenInGitGui- 和 OpenInGitX- 为 前 级 的 软件 包 ， 可 以 分 别 实现 与 git 
gui 和 gitx 的 整合 ;在 Finder 中 进入 工作 区 目录 ， 点 击 对 应 插件 的 图 标 ， 
启动 git gui 或 gitx。 





3.2.7 ”中 文 支持 


由 于 Mac OS 义 采 用 Unix 内 核 ， 在 中 文 支 持 上 与 Linux 相 近 ， 具 体内 


容 请 参照 第 3.1.5 节 介绍 的 在 Linux 下 安装 Git 的 相关 内 容 。 


[1] http:/ /www.macports.org/ 
[2] http:/ /www.finkproject.org/ 


[3] http:/ /mxcl.github.com/homebrew/ 


3.3 在 Windows 下 安装 和 使 用 Git (Cygwin 篇 ) 


在 Windows 下 安装 和 使 用 Git 有 两 种 不 同 的 方案 : 通过 安装 msysGit 
趾 或 Cygwin 中 来 使 用 Git。 在 这 两 种 不 同 的 方案 下 ，Git 的 使 用 与 Linux 
环境 下 完全 一 致 。 还 可 以 通过 msysGit 的 图 形 界面 软件 TortoiseGit 1 (也 
就 是 在 CVS 和 SVN 时 代 就 已 经 广为人知 的 Tortoise 系 列 软件 的 Git 版 本 ) 
来 使 用 Git。TortoiseGit 可 与 资源 管理 器 整合 ， 从 而 提供 Git 操 作 的 图 形 化 
界面 。 





首先 介绍 通过 Cygwin 来 使 用 Git， 并 不 是 因为 这 是 最 便捷 的 方法 。 
如 果 需 要 在 Windows 中 快速 安装 和 使 用 Git， 下 一 节 介 绍 的 msysGit 才 是 
最 便捷 的 方法 。 之 所 以 将 Cygwin 放 在 前 面 介绍 是 因为 本 书 在 介绍 Git 原 
理 和 其 他 Git 相 关 的 软件 时 用 到 了 大 量 的 开源 工具 ， 在 Cygwin 下 很 容易 
获得 这 些 开 源 工具 ， 而 msysGit 的 MSYS11 (Minimal SYStem， 最 简 系 
统 ) 则 不 能 满足 我 们 的 需求 。 因 此 ， 我 建议 Windows 平 台 下 的 读者 在 跟 
随 本 书 学 习 Git 的 过 程 中 首选 Cygwin， 当 对 Git 有 了 一 定 的 了 解 后 ， 无 论 
是 msysGit 还 是 TortoiseGit， 您 都 会 应 对 自如 。 





Cygwin 是 一 款 伟 大 的 软件 ， 通 过 一 个 小 小 的 DLL (cygwin1.dll) 建 
并 了 Linux 与 Windows 之 间 的 系统 调用 和 API 之 间 的 转换 ， 使 得 Linux 下 
的 绝 大 多 数 软 件 能 同 Windows 迁 移 。Cygwin 通 过 cygwin1.dll 所 建立 的 中 


间 层 与 YMWare 中” 、VirtualBox [6 等 虚拟 机 软件 完全 不 同 ， 不 会 独占 系 
统 资 源 。 像 VMWare 等 虚拟 机 ， 只 要 启动 一 个 虚拟 机 (操作 系统 ) ， 即 
使 不 在 其 中 执行 任何 命令 ， 同 样 也 会 占用 大 量 的 内 存 和 CPU 时 间 等 系统 


Cygwin 还 提供 了 一 个 强大 易 用 的 包 管 理工 具 (setup.exe) ， 使 得 几 
于 个 开源 软件 包 能 在 Cygwin 下 便捷 地 安装 和 升级 ，Git 便 是 其 中 的 一 


3 





我 对 Cygwin 有 着 深厚 的 感情 ，Cygwin 让 我 能 在 Windows 平 台 下 用 
Linux 的 方式 更 有 效率 地 工作 ， 使 用 Linux 风 格 的 控制 台 蔡 换 Windows 黑 
乎 乎 的 、 冷 冰冰 的 、 由 cmd.exe 提 供 的 命令 行 。Cygwin 帮 助 我 逐渐 摆脱 
对 Windows 的 依赖 ， 当 我 完全 转换 到 Linux 平 台 时 ， 没 有 感到 一 丝 的 障 


但 。 





3.3.1 ”安装 Cygwin 


Cygwin 的 安装 非常 简单 ， 先 在 其 官方 网 站 http://www.cygwin.com/ 
下 载 安装 程序 一 一 一 个 只 有 几 百 KB 的 setup.exe 文 件 ， 然 后 即 可 开始 安 
闭 。 





安装 过 程 中 会 让 用 户 选择 安装 模式 ， 通 过 网 络 安装 、 下 载 后 安装 或 
者 通过 本 地 软件 包 缓 存 〈 安 装 时 自动 在 本 地 目录 下 建立 的 软件 包 缓存 ) 





(1) 如 果 是 第 一 次 安装 Cygwin， 因 为 本 地 尚 没有 软件 包 缓 存 ， 当 
然 只 能 选择 从 网 络 安装 ， 如 图 3-4 所 示 。 





Cygwin Setup - Choose Installation Type 
Choose A Download Source C 


Choose whether to install or download from the internet, or install from files im 
alocal directory. 


Beenesnneterttt rmt tnt tri 上 上】 上】 上】 


© Download without Installing 


© Install from Local Directory 





图 3-4 选择 安装 模式 


(2) 选择 安装 目录 ， 默 认为 C:\cygwin， 如 图 3-5 所 示 。 这 个 目录 将 
作为 Cygwin shell 环 境 的 根 目录 〈 根 卷 ) ，Windows 的 各 个 盘 符 将 挂 载 在 
根 卷 的 一 个 特殊 目录 之 下 。 








Cygwin Setup - Choose Installation Directory 


Select Root Install Directory 


Select the directory where you want to Install Cygwin. Also choose a few 
installation parameters. 


Root Directory 





{® AllUsers [RECOMMENDED) 
Cygwin will be available to all users of the system. 


© JustMe 
Cygwin will still be available to all users, but Desktop Icons, Cygwin Menu Entries, and 


Important Installer nformation are only available to the current user. Only select this if 
you lack Administrator privileges or if you have specific needs. 





图 3-5 ”选择 安装 目录 


(3) 设置 本 地 软件 包 缓存 目录 ， 默 认为 setup.exe 所 处 的 目录 ， 如 
图 3-6 所 示 。 


~ Cygwin Setup - Select Local Package Directory | -|D| x| 


Select Local Package Directory 
Select a directory where you want Setup to store the installation fles tt 
downloads The directory will be created if it does not already exist. 








广 Local Package Directory 
C:\Documents and Settings\Jiang xsin\My Documents\Downloadg Browse... | 











< Back Cancel | 





图 3-6 ”选择 本 地 软件 包 缓 存 目录 


(4) 设置 网 络 连接 方式 是 否 使 用 代理 等 ， 如 图 3-7 所 示 。 默 认 会 选 
择 第 一 项 :“ 直 接 网 络 连接 *。 如 果 一 个 团队 有 很 多 人 要 使 用 Cygwin， 染 
设 一 个 能 够 提供 软件 包 缓存 的 HTTP 代 理 服务 器 会 节省 大 量 的 网 络 带宽 
和 大 量 的 时 间 。 在 Debian/Ubuntu 下 用 apt-cacher-ng1 | 就 可 以 非常 简单 地 
搭建 一 个 软件 包 代 理 服 务 器 。 图 3-7 显 示 的 就 是 我 在 公司 内 网 中 安装 
Cygwin 时 使 用 内 网 的 服务 器 bj.ossxp.com 作 为 HTTP 代 理 的 情形 ， 端 口 设 
置 为 9999， 因 为 这 是 apt-cacher-ng 的 默认 端口 。 


~ Cygwin Setup - Select Connection Type 加 | 口 | x] 


Select Your Internet Connection C 


Setup needs to know how you want it to connect to the intemet. Choose 
the appropriate settings below. 





© Direct Connection 


© Use lnternetExplorer Proxy Settings 
f UseHTTP,FTP Prowy: 









Proxy Host [biossxp.com 
Port [3993 





coee | 





图 3-7 是 否 使 用 代理 下 载 Cygwin 软 件 包 


(5) 选择 一 个 Cygwin 源 ， 如 图 3-8 所 示 。 如 果 在 上 一 个 步骤 中 选择 
使 用 HTTP 代 理 服务 器 ， 就 必须 选择 HTTP 协 议 的 Cygwin 源 。 


~ Cygwin Setup - Choose Download Sitefs) | -| 口 | x| 


Choose A Download Site 
Choose a site from this list, or add your own sites to the list C 


点 vallable Download Sites: 


http: /7/cygwinmirror. 3gforphones.com 
http: cygwin.rmmirrors.hooblycom 
http: /A/cygwin. myamplifiers.com 

ftp: A/ cygwin. mirrors. pait.com 

http: 2/ /cygwin. mirrors.pair.com 
http://cygwin.parentingamerica.com 
http: A/cygwin. skazkaforyou.com 

ftp: Armirrors.xmission.com 

http: mirrors.8mission.com 

http: Amiror.calyin.edu 

ftp: 2 ftp.athb.gatech.edu 

http: www.gtib.gatech.edu 

ftp: mirrorlts. uidaho. edu 了 | 
I PP 







User URL: | | 
eee | 





图 3-8 ”选择 Cygwin 源 


(6) 从 所 选 的 Cygwin 源 下 载 软件 包 过 引文 件 ， 然 后 显示 软件 包 管 
理 占 界面 ， 如 图 3-9 所 示 。 


~ Cyowin Setup - Select Packages S99 16 
Select Packages 
Select packages to install 
Search | Clear| 人 Keep 人 Prev 和 Cur © Exp View | Category 
Se Packse 


A Default 
hccessibility 入 Default 
Admin 6 Default 
archive 4 Default 

点 udio 各 Default 

Base *¥ Default 
Database 4 Default 
Devel 各 Default 
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图 3-9 Cygwin 软件 包 管 理 器 


Cygwin 的 软件 包 管 理 需 非常 强大 ， 而 且 易 于 使 用 〈 如 宁 习 惯 了 其 界 
面 ) 。 软 件 包 归 类 于 各 个 分 组 中 ， 点 击 分 组 前 的 加 号 就 可 以 展开 分 组 。 
在 展开 的 Admin 分 组 中 ， 如 图 3-10 所 示 (这 个 截图 不 是 首次 安装 Cygwin 
的 截图 ) ， 有 的 软件 包 《〈 如 libattr1) 已 经 安装 过 了 ， 因 为 没有 新 版 本 而 
标记 为 “Keep”( 保 持 ) ， 没 有 安 六 过 并 且 不 准备 安装 的 软件 包 则 标记 
为 “Skip”( 跳 过 ) 。 


~ Cygwin Setup - Select Packages | E 一 [DI| X| 


Select Packages 
Select packages to install 





Search | Clear | 全 Keep 人 Prev 和 Cur OF Esp ~ View | Category 










日 A Default 
accessibilty #¥ Default 
Admin 好 Default 





ma nja 55k attr Util 
na nia 58k cron: Vi 
nia nia 3Bk cygrunsi 
na 口 ek libattrl: : 
ma nfa Bk shutdow 
na na 254kK oa a 


[fw Hide obsolete packages 
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图 3-10 Cygwin 软件 包 管 理 器 展开 分 组 


(7) 点 击 分 组 名 称 后 面 的 动作 名 称 〈 文 字 “Default*) ， 会 进行 软 
件 包 安 装 动 作 的 切换 。 例 如 图 3-11， 将 Admin 分 组 的 安装 动作 
由 “Default” (默认) 切换 为 “Install”( 安 装 ) ， 会 看 到 Admin 分 组 下 的 所 
有 软件 包 都 标记 为 安装 (显示 具体 要 安装 的 软件 包 版 本 号 ) 。 也 可 以 通 
过 鼠标 点 击 ， 单 独 为 软件 包 进 行 安装 动作 的 设 定 : 可 以 强制 重新 安装 、 
安装 旧版 本 ， 或 者 不 安装 。 


~ Cygwin Setup - Select Packages | | 口 | x| 


Select Packages 

Select packages to install C 
Search| Clear| 人 Keep (~ Blev {* Cur © Exp View | Category 
ego [Cm INew [6 lS [Se |Pcka 










日 A Default 

accessibility #3 Default 

日 上 dmin #3 Install 
和 2443-1 口 55k attr: Util 
4 二 1.59 口 58k cron: wy 
*¥ 1.34-1 口 36k cygruns! 

2.4.43:1 *¥ Keep na 口 ak libattrl:! 

*¥ 1.7-1 口 Bk shutdow 
#3.2.1-1 BI 门 


254k wo 
> 


Jw Hide obsolete packages 
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图 3-11 安装 菜 一 分 组 下 的 所 有 软件 


(8) 当 通 过 软件 包 管 理 器 对 要 安 闭 的 软件 包 定 制 完毕 后 ， 点 击 下 
一 步 ， 开 始 下 载 软件 包 、 安 装 软件 包 和 软件 包 后 处 理 (postinstall) ， 直 
至 完成 安装 。 根 据 选 择 的 软件 包 的 多 少 、 网 络 情况 ， 以 及 是 人 否 架 设 有 代 
理 服务 器 等 情况 的 不 同 ， 首 次 安装 Cygwin 的 时 间 可 能 从 几 分 钟 到 几 个 小 
时 不 等 。 


3 “Git 





默认 安装 的 Cygwin 没 有 安装 Git 软 件 包 。 如 果 在 首次 安装 过 程 中 环 
通过 包 管 理 器 选择 安装 Git 或 其 他 相关 软件 包 ， 可 以 在 安装 后 再 次 运 
行 Cygwin 的 安装 程序 setup.exe。 当 再 次 进入 Cygwin 包 管理 器 界面 时 ， 在 

搜索 框 中 输入 git， 如 图 3-12 所 示 。 





从 图 3-12 中 可 以 看 出 在 Cygwin 中 包含 了 很 多 与 Git 相 关 的 软件 包 ， 
把 这 些 Git 相 关 的 软件 包 全 部 都 安装 上 吧 ， 如 图 3-13 所 示 。 


需要 安装 的 其 他 软件 包 还 有 : 


git-completion: 提供 Git 命 令 的 自动 补 齐 功能 装 该 软件 包 时 会 


自动 安装 其 所 依赖 的 bash-completion 软 件 包 
.openssh: SSH 客 户 端 ， 为 访问 SSH 协 议 的 版 本 库 提 供 支 持 。 


. vim: Git 默 认 的 编辑 器 。 


~ Cygwin Setup - Select Packages | ~ 上 口 | x| 


Select Packages 
Select packages to install C 
Search [oi Clear | CT keep CF Prev PC Cur FF Exp ~ View | Category 














日 上 4 Default 
日 Devel 4 Default 


各 5kip na nia 2.639k git Fast Version Col 
各 5kip na nja 13k git-completion: Fast 
#¥ Skip na nja 174k git-gut Fast Version 
各 5kip na nja BOk git-syn: Fast Yersior 
各 5kip na nja 102k aitk: Fast Version C 







nia nia 476k stat: Quilt functiona 
Puthon # Default 


Jv Hide obsolete packages 





图 3-12 ”Cygwin 软件 包 管理 器 中 搜索 git 


~ Cygwin Setup - Select Packages i -ID|x| 


Select Packages 
Select packages to install C 


Search [oat Clear| 人 六 Keep FC Brevy (* Cur FF Exp ~ View | Category 
| Categoy | Curent |New |B.| SS..| 


日 BI #7 Default 
日 Devel #Y Install 














他 1.7.3.3:1 口 2,633k glt Fast Yersion [ol 
从 1.7.3.3.1 口 13k git-completion: Fast 
#¥ 1.7.3.3:1 口 174k git-gur Fast Version 
和 1.7.3.3-1 口 BOk git-svn: Fast Yersior 
1.7.3.3-:1 口 102k gitk: Fast Version C: 
015-2 口 476k stglk Quilt functiona 





Puthon 各 Default 


Jv Hide obsolete packages 





图 3-13 ”Cygwin 软件 包 管理 器 中 安装 git 


3.3.3 Cygwin 的 配置 和 使 用 
运行 Cygwin 后 会 进入 shell 环 声 并 见 到 熟悉 的 Linux 提 示 符 ， 如 图 3- 
14 上 所 示 。 


可 以 通过 执行 cygcheck 命 令 来 查看 Cygwin 中 安装 的 软件 包 的 版 本 。 
例如 ， 查 看 Cygwin 软 件 包 本 身 的 版 本 : 





$ cygcheck -c cygwin 
Cygwin Package Information 


Package Version Status 
cygwin 1.7.7-1 OK 


= 
Copying skeleton files. a 
These files are for the user to personalise their cygwin experience. 





They will never be overwritten nor automatically updated. 


‘./.bashre' -> /home/jiangxin//.bashre' 
‘./.bash_profile' -> /home/jiangxin//.bash_profile' 
‘./.inputre' -> /home/jiangxin//.inputre' 


# uname ~-r 
1.7.7(0.230/5/3) 


#3 pwd 
/home/jiangxin 





图 3-14 运行 Cyewin 
1. 如 何 访问 Windows 的 盘 符 


刚刚 接触 Cygwin 的 用 户 遇 到 的 头 一 个 问题 就 是 : Cygwin 如 何 访问 
Windows 的 各 个 磁盘 目录 ， 以 及 在 Windows 平 台 下 如 何 访问 Cygwin 中 的 
目录 。 





执行 mount 命 令 后 可 以 看 到 Windows 下 的 盘 符 被 映射 到 /cygdrive 特 殊 
目录 下 。 





$ mount 

C:/cygwin/bin on /usr/bin type ntfs (binary, auto) 

C:/cygwin/lib on /usr/lib type ntfs (binary, auto) 

C:/cygwin on / type ntfs (binary, auto) 

C: on /cygdrive/c type ntfs (binary, posix=0, user, noumount, auto) 


D: on /cygdrive/d type ntfs (binary, posix=0, user, noumount, auto) 





也 就 是 说 ， 在 Cygwin 中 以 路 径 /cygdrive/c/Windows 来 访问 Windows 
下 的 C:\Windows 目录 。 实 际 上 ，Cygwin 提 供 cygpath 命 令 来 实现 
Windows 平 台 和 Cygwin 之 间 目 录 名 称 的 变换 ， 如 下 所 示 : 





$ cygpath -u C:\\Windows 
/cygdrive/c/Windows 

$ cygpath -w ~/ 
C:\cygwin\home\jiangxin\ 





从 上 面 的 示例 也 可 以 看 出 ，Cygwin 下 的 用 户主 目录 
( 即 /home/jiangxin/〉 相当 于 Windows 下 的 C:\cygwin\home\jiangxin\ 晶 
J 


2. 用 户主 目录 不 一 致 的 问题 


如 果 某 些 其 他 软件 〈 如 msysGit) 为 Windows 设 置 了 HOME 环境 变 
量 ， 会 影响 到 Cygwin 中 用 户主 目录 的 设置 ， 甚 至 会 造成 在 Cygwin 中 不 
同 的 命令 有 不 同 的 用 户主 目录 的 情况 。 例 如 : Cygwin 下 Git 的 用 户主 日 
录 被 设置 为 /cygdrive/c/Documents and Settings/jiangxin， 而 SSH 客 户 端 软 
件 的 主 目录 被 设置 为 home/jiangxin， 这 会 给 用 户 造 成 困惑 。 








之 所 以 出 现 这 种 情况 ， 是 因为 Cygwin 确 定 用 户主 目录 有 几 个 不 同 的 
依据 ， 要 按照 顺序 确定 主 目录 : 首先 租 看 系统 的 HOME 环境 变量 ， 其 次 
查看 /etc/passwd 中 为 用 户 设置 的 主 目录 。 有 的 软件 遵照 这 个 原则 ， 而 有 








些 Cygwin 应 用 如 SSH， 却 没有 使 用 HOME 环境 变量 而 是 直接 使 
用 /etc/passwd 中 的 设置 。 要 想 避 免 在 同一 个 Cygwin 环 境 下 有 两 个 不 同 的 
用 户主 目录 设置 ， 可 以 采用 下 面 两 种 方法 。 








. 方法 1: 修改 Cygwin 启 动 的 批 处 理 文件 (如 : 
C:\cyewin\Cyewin.bat) ， 在 批 处 理 的 开头 添加 如 下 的 一 行 代 码 ， 就 可 以 
防止 其 他 软件 在 Windows 引 入 的 HOME 环 境 变 量 被 带 入 到 Cygwin 中 。 





set HOME= 





“ 方法 2: 如 果 希 望 使 用 HOME 环 境 变 量 指向 的 主 目录 ， 则 可 通过 
手工 编辑 /etc/passwd 文 件 ， 将 其 中 的 用 户主 目录 修改 成 HOME 环境 变量 
所 指向 的 目录 由。 


3. 命 令 行 补 齐 忽 略 文 件 名 大 小 写 

Windows 的 文件 系统 忽略 文件 名 的 大 小 写 ， 在 Cygwin 下 最 好 对 命令 
行 补 齐 进行 相关 设置 ， 以 忽略 大 小 写 ， 这 样 使 用 起 来 更 方便 。 

编辑 文件 ~/.inputrc， 在 其 中 添加 设置 “set completion-ignore-case 
on”， 或 者 取消 已 有 的 相关 设置 前 面 的 井 (#) 号 注释 符 。 修 改 完 毕 后 ， 
再 重新 进入 Cygwin， 这 样 就 可 以 实现 命令 行 补 齐 对 文件 名 大 小 写 的 忽 
略 。 


4. 忽 略 文件 权限 的 可 执行 位 


Linux、UNIX、Mac OS X 通 过 文件 权限 中 的 可 执行 位 判断 文件 是 否 
可 执行 ， 而 Windows 是 通过 文件 扩展 名 进行 判断 的 。Git 提 供 对 类 UNIX 
系统 文件 权限 的 支持 ， 在 版 本 库 中 建立 对 可 执行 文件 的 追踪 。 对 于 
Windows 平 台 ，Git 的 这 个 特性 用 处 不 大 ， 甚 至 有 害 。 因 为 ， 虽 然 
Cygwin 可 以 模拟 Linux 下 的 文件 授权 并 对 文件 的 可 执行 位 提供 支持 ， 但 
为 支持 文件 权限 而 调用 Cygwin 的 stat () 函数 和 lstat () 函数 会 比 调用 
Windows 自 身 的 Win32 API 要 慢 一 半 ， 而 且 非 跨 平 台 的 项 目 也 没有 必要 
对 文件 权限 位 进行 跟踪 ， 甚 至 Windows 下 的 其 他 工具 及 操作 可 能 会 破坏 
文件 的 可 执行 位 ， 从 而 导致 Cygwin 下 的 Git 认 为 文件 的 权限 更 改 需 要 重 
新 提交 。 通 过 下 面 的 配置 可 以 禁止 Git 对 文件 权限 的 跟踪 : 














$ git config --system core.fileMode false 








在 此 模式 下 ， 当 已 添加 到 版 本 库 中 的 文件 的 权限 的 可 执行 位 改变 
时 ， 该 文件 不 会 显示 有 改动 。 版 本 库 中 新 增 的 文件 ， 无 论文 件 本 身 是 否 
设置 为 可 执行 ， 都 以 100644 的 权限 (忽略 可 执行 位 〉 进 行 添加 。 





关于 Cygwin 的 更 多 内 容 ， 请 参见 网 


址 http://www.cygwin.com/cygwin-ug-net/ 中 的 信息 。 


3.3.4 Cygwin 下 Git 的 中 文 支持 





Cygwin 的 当前 版 本 是 1.7.x， 对 中 文 的 支持 非常 好 。 无 需 任 何 配置 就 
可 以 在 Cygwin 的 窗口 内 输入 中 文 ， 执行 ls 命 令 就 可 以 显示 中 文 的 文件 
名 。 这 与 六 七 年 前 的 Cygwin 1.5.x 完 全 不 一 样 了 ， 老 版 本 的 Cygwin 还 需 
要 进行 一 些 配置 才能 在 控制 台 输 入 中 文 和 显示 中 文 ， 但 是 最 新 版 本 的 
Cygwin 已 经 完全 不 需要 了 。 后 面 要 介绍 的 msysGit 的 shell 环 境 仍 然 需 要 
进行 相关 的 配置 〈 同 老 版 本 Cygwin) 才能 够 正常 显示 和 输入 中 文 。 








Cygwin 默 认 使 用 UTF-8 字 符 集 ， 并 能 巧妙 地 与 Windows 系 统 的 字符 
集 进行 转换 。 在 Cygwin 下 可 执行 locale 命 令 查 看 Cygwin 下 正在 使 用 的 字 


符 集 : 





$ locale 

LANG=C .UTF-8 
LC_CTYPE="C.UTF-8" 
LC_NUMERIC="C.UTF-8" 
LC_TIME="C .UTF-8" 
LC_COLLATE="C.UTF-8" 
LC_MONETARY="C .UTF-8" 
LC_MESSAGES="C .UTF-8" 
LC_ALL= 





正 因 为 如 此 ，Cygwin 下 的 Git 对 中 文 的 支持 也 非常 出 色 。 昌 然 中 文 
的 Windows 本 里 使 用 GBK 字 符 集 ， 但 是 在 Cygwin 下 ，Git 束 如 同 工 作 在 
采用 UTF-8 字 符 集 的 Linux 下 ， 对 中 文 的 文 持 非常 的 好 : 





` 在 提交 时 ， 可 以 在 提交 说 明 中 输入 中 文 。 


显示 提交 历史 时 ， 能 够 正常 显示 提交 说 明 中 的 中 文字 符 。 


. 可 以 添加 文件 名 称 为 中 文 的 文件 ， 并 可 以 在 使 用 UTF-8 字 符 集 的 
Linux 环 境 中 克隆 和 检 出 。 


. 可 以 创建 带 有 中 文字 符 的 里 程 碑 名 称 。 





但 是 和 Linux 平 台 一 样 ， 在 默认 设置 下 ， 文 件 名 称 中 包含 中 文 的 文 
件 ， 在 工作 区 状态 输出 、 碍 看 历史 更 改 概要 ， 以 及 在 补丁 文件 中 ， 文 件 
名 中 的 中 文 不 能 正确 地 显示 ， 而 是 用 若干 八进制 字符 编码 来 显示 ， 如 
下 : 











$ git status -s 

?7 "\350\257\264\346\230\216.txt" 

$ printf "\350\257\264\346\230\216.txt" 
说 明 .txt 





配置 变量 core.quotepath 设 置 为 false 就 可 以 解决 中 文 文件 名 在 这 些 Git 


命令 输出 中 的 显示 问题 。 





$ git config --global core.quotepath false 
$ git status -s 
?3 说 明 .txt 





3.3.5 Cygwin 下 Git 访 问 SSH 服 务 





在 本 书 第 5 篇 第 29 章 中 介绍 的 以 公 钥 认证 的 方式 访问 Git 服 务 ， 是 实 
现 Git 写 操作 的 最 重要 的 服务 。 以 公 钥 认证 方式 访问 SSH 协 议 的 Git 服 务 
器 时 无 须 输 入 口令 ， 而 且 更 安全 。 使 用 公 钥 认证 就 涉及 如 何 创 建 公 钥 / 


私 钥 对 ， 以 及 在 SSH 连 接 时 应 该 选择 哪 一 个 私 钥 的 问题 (如 果 建 并 有 多 
小 私 铜 六 


Cygwin 下 的 openssh 软 件 包 提供 的 ssh 命 令 和 Linux 下 的 ssh 命 令 没有 
什么 区 别 ， 也 提供 了 ssh-keygen 命 令 来 管理 SSH 公 钥 / 私 钥 对 。 但 是 ， 
Cygwin 当 前 的 openssh 〈 版 本 号 : 5.7p1-1) 有 一 个 Bug， 使 用 Git 克 隆 采 
用 SSH 协 议 的 版 本 库 时 偶尔 会 中 断 ， 从 而 无 法 完成 版 本 库 的 克隆 。 示 例 
如 下 : 








$ git clone git@bj.ossxp.com:ossxp/gitbook.git 

Cloning into gitbook... 

remote: Counting objects: 3486, done. 

remote: Compressing objects: 100% (1759/1759), done. 

fatal: The remote end hung up unexpectedly MiB | 3.03 MiB/s 
fatal: early EOFs: 75% (2615/3486), 13.97 MiB | 3.03 MiB/s 
fatal: index-pack failed 





如 果 您 也 遇 到 同样 的 问题 ， 建 议 使 用 PuTTY 提 供 的 plink.exe 作 为 
SSH 客 户 端 ， 蔡 代 Cygwin 自 带 的 ssh 命 令 。 


1. 安 装 PuTTY 


PuTTY 是 Windows 下 的 一 个 开源 软件 ， 提 供 SSH 客 户 端 服务 ， 还 包 
括 公 钥 管 理 的 相关 工具 。 访 问 PuTTY 的 主页 
(http:/www.chiark.greenend.org.uk/~sgtatham/putty/ ) ， 下 载 并 安装 
PuTTY。 安 装 完毕 会 发 现 PuTTY 软 件 包 包含 了 多 个 可 执行 程序 ， 下 面 几 
个 命令 用 于 与 Git 的 整合 。 





Plink: 即 blink.exe， 有 是 命令 行 的 SSH 客 户 端 ， 用 于 替代 ssh 命 令 。 


默认 安装 于 C:\Program Files\PuTTYNplink.exe 路 径 中 。 


. PuTTYgen: 用 于 管理 PuTTY 格 式 的 私 铀 ， 也 可 以 用 于 将 openssh 
格式 的 私 钥 转换 为 PuTTY 格 式 的 私 钥 。 


* Pageant: SSH 认 证 代理 ， 运 行 于 后 台 ， 负 责 为 SSH 连 接 提供 私 铀 


访问 服务 。 
2.PuTTY 格 式 的 私 铀 


PuTTY 使 用 专 有 格式 的 私 钥 文件 〈 扩 展 名 为 .ppk) ， 而 不 能 直接 使 
用 openssh 格 式 的 私 钥 。 也 就 是 用 openssh 的 ssh-keygen 命 令 创建 的 私 钥 不 
能 直接 被 PuTTY 合 过 来 使 用 ， 必 需 经 过 转换 ， 程 序 PuTTYgen 可 以 实现 
私 钥 格 式 的 转换 。 


运行 PuTTYgen 程 序 ， 如 图 3-15 所 示 。 


2 PulTTY Key Generator 
Fie Key Conversions Help 


Key 
No key. 


Actions 

Generate a public/private key palr 
Load an existing private key flle Pe ea 
5ave the generated key 


Parameters 


Type of key to generate: 
© 5SH-1 (RSA) © 55H-2RSA OssH-:2D5A 


Number of bits in a generated key: [ 024 





图 3-15 运行 PuTTYgen 程 序 


PuTTYgen 既 可 以 重新 创建 私 钥 文件 ， 又 可 以 通过 点 击 加 载 按钮 
Goad) 读 取 openssh 格 式 的 私 钥 文件 ， 从 而 可 以 将 其 转换 为 PuTTY 格 式 
的 私 钥 。 点 击 加 载 按钮 ， 会 弹出 文件 选择 对 话 框 ， 选 择 openssh 格 式 的 
私 钥 文 件 〈 如 文件 id_rsa) ， 如 果 转 换 成 功 ， 会 显示 如 图 3-16 的 界面 。 


gc PUTJJY Key Generator 
Fie Key Conversions Help 


Key 
Public key for pasting into OpenSSH authorized_keys file: 


| 

| Ssh-rsa 

| oaaB3NzaClyc2EAaAaBINaasDEAOcD+ciVEwooAn9zalNw3bplZ00ukeRHHes 
AimQchfVICs4T3LEywzwWa7ogs188aa 一 一 一 
5SMOQIFb3kiuR4BpU4hadwwcQLaok PUTJJYgen Notice 

|YwPsa5tpuPUYD sulfRBR7zUor+y+5 


fi Een Successfully imported foreign key 
oo et A j) (Opens5H 55H-2 private key), 
Kev comment: |imported-ope To use this key with PuTTY, you need to 
EE 3 Use the "Save private key" command to 
Key passphrase: save it in PuTTY's own Format， 








Confrm passphrase: 


Sctions 


Generate a public/private key palr 


Load an existing private key file 


Save the generated key Save public key Save plivate key 


Parameters 


Type of key to generate: 
OO 55H-1 (BSA) © 55H-2 RSA O SSH-2D5A 


Number of bits in a generated key: |1024 











图 3-16 ”PuTTYgen 完 成 私 钥 加 载 


然后 点 击 “Save private key”( 保 存 私 钥 〉 ， 就 可 以 将 私 钥 保 存 为 
PuTTY 的 .ppk 格 式 ， 例 如 将 私 钥 保存 到 文件 ~/.ssMVjiangxin-cygwin.ppk 
中 。 


3.Git 使 用 Pageant 进 行 公 钥 认 证 


Git 在 使 用 命令 行 工 具 Plink (plink.exe) 作为 SSH 客 户 端 访问 SSH 协 
议 的 版 本 库 服 务 器 时 ， 如 何 选择 公 钥 呢 ? 使 用 Pageant 是 一 个 非常 好 的 选 
择 。Pageant 是 PuTTY 软 件 包 中 的 代理 软件 ， 为 各 个 PuTTY 应 用 提供 私 钥 
请 求 ， 当 Plink 连 接 SSH 服 务 器 需要 请 求 公 钥 认证 时 ，Pageant 就 会 给 
Plink 提 供 相应 的 私 钥 。 





运行 Pageant， 局 动 后 会 在 托盘 区 显示 一 个 图 标 ， 在 后 台 运 行 。 使 用 
鼠标 右键 单 击 Pageant 的 图 标 ， 就 会 弹出 相关 的 沫 单 ， 如 图 3-17 所 示 。 


NEV Session 
Saved Sessions > 


Yiew Keys 
dd Key 


Help 
Lbout 


EXR 





图 3-17 Pageant 的 弹出 菜单 


点 击 弹 出 菜单 中 的 “Add Key”( 添 加 私 钥 〉 按钮 ， 会 弹出 文件 选择 
框 ， 选 择 扩 展 名 为 .ppk 的 PuTTY 格 式 的 公 钥 ， 即 完成 了 Pageant 的 私 钥 准 


备 工作 。 


接 下 来 ， 还 需要 对 Git 进 行 设置 ， 设 置 Git 使 用 plink.exe 作 为 SSH 客 户 
端 ， 而 不 是 默认 的 ssh 命 令 。 通 过 设置 GIT_SSH 环 境 变量 即 可 实现 : 








$ export GIT_SSH=/cygdrive/c/Program\ Files/PuTTY/plink.exe 





上 面 在 设置 GIT_SSH 环 境 变 量 的 过 程 中 使 用 了 了 Cygwin 格式 的 路 径 ， 
而 非 Windows 格 式 的 ， 因 为 Git 是 在 Cygwin 的 环境 中 调用 plink.exe 命 令 
的 ， 所 以 要 使 用 Cygwin 能 够 理解 的 路 径 。 


这 样 就 可 以 用 Git 访 问 SSH 协 议 的 Git 服 务 右 了 。 运 行 在 后 全 的 
Pageant 会 在 需要 的 时 候 为 plink.exe 提 供 私 钥 访 问 服 务 ， 但 在 首次 连接 一 
个 使 用 SSH 协 议 的 Git 服 务 器 的 时 候 ， 很 可 能 会 因为 远程 SSH 服 务 器 的 公 
钥 没 有 经 过 确认 而 导致 git 命 令 执行 失败 。 例 如 : 





$ git clone git@bj.ossxp.com:ossxp/gitbook.git 

Cloning into gitbook... 

The server's host key is not cached in the registry. You 
have no guarantee that the server is the computer you 

think it is. 

The server's rsa2 key fingerprint is: 

ssh-rsa 2048 49:eb:04:30:70:ab:b3:28:42:03:19:fe:82:f8:1a:00 
Connection abandoned. 

fatal: The remote end hung up unexpectedly 





这 是 因为 在 首次 连接 SSH 服 务 器 时 要 对 其 公 钥 进行 确认 (以 防止 被 
钓鱼 ) ， 而 运行 于 Git 下 的 plink.exe 没 有 机 会 从 用 户 那 里 获取 输入 ， 以 建 
立 对 该 SSH 服 务 器 公 钥 的 信任 ， 因 此 Git 访 问 失败 。 解 决 办 法 非常 简单 ， 





直接 运行 plink.exe 连 接 一 次 远程 SSH 服 务 器 ， 并 对 公 钥 确认 进行 应 答 即 
可 。 操 作 如 下 : 





$ /cygdrive/c/Program\ Files/PuTTY/plink.exe git@bj.ossxp.com 
The server's host key is not cached in the registry. You 
have no guarantee that the server is the computer you 

think it is. 

The server's rsa2 key fingerprint is: 

ssh-rsa 2048 49:eb:04:30:70:ab:b3:28:42:03:19:fe:82:f8:1a:00 
If you trust this host, enter "y" to add the key to 

PUTTY'S cache and carry on connecting. 

If you want to carry on connecting just once, without 
adding the key to the cache, enter "n". 

If you do not trust this host, press Return to abandon the 
connection. 

Store key in cache? (y/n) 





输入 “y”， 将 公 钥 保存 在 信任 链 中 ， 以 后 再 和 该 主机 连接 时 就 不 会 
弹出 该 确认 应 答 了 。 当 然 ，Git 命 令 也 就 可 以 成 功 执行 了 。 


4. 使 用 自 定 义 SSH 脚 本 取代 Pageant 





使 用 Pageant 时 还 要 在 它 每 次 局 动 时 手动 选择 私 钥 文 件 ， 这 比较 麻 
烦 。 实 际 上 ， 可 以 创建 一 个 脚本 对 plink.exe 进 行 封装 ， 在 封装 的 脚本 中 
使 用 -i 参数 指定 私 钥 文 件 。 


例如 ， 创 建 脚本 ~/bin/ssh-jiangxin， 文 件 内 容 如 下 : 





#!1/bin/sh 
/cygdrive/c/Program\ Files/PuTTY/plink.exe -T -i \ 
c:/cygwin/home/jiangxin/.ssh/jiangxin-cygwin.ppk $* 





设置 该 脚本 为 可 执行 脚本 。 





$ chmod a+x ~/bin/ssh-jiangxin 





使 用 下 面 的 命令 通过 该 脚本 与 远程 SSH 服 务 右 连接 : 





$ ~/bin/ssh-jiangxin git@bj.ossxp.com 
Using username "git",. 
hello jiangxin, the gitolite version here is v1.5.5-9-g4c11bd8 
the gitolite config gives you the following access: 
gistore-bj.ossxp.com/.*$ 
gistore-ossxp.com/.*$ 
OSsxp/.*$ 
test/repol1 
test/repo2 
test/repo3 
@R @W test/repo4 
@C @R W users/jiangxin/.+$ 


必 必 力 必 必 思 





设置 GIT_SSH 变 量 ， 使 之 指 同 新 建立 的 脚本 ， 然 后 就 可 以 脱离 
Pageant 来 连接 SSH 协 议 的 Git 库 了 。 





$ export GIT_SSH=~/bin/ssh-jiangxin 





[1] http://code.google.com/p/msysagit/ 

[2] http:/ /www.cyewin.com/ 

[3] http://code.google.com/p/tortoisegit/ 

[4] http:/ /www.mingw.org/ wiki/msys 

[5] http:/ /www.vmwate.com/ 

[6] http:/ /www.virtualbox.org/ 

[7] http://www.unix-ag.uni-kl.de/ ~bloch/acng/ 


[8] http:/ /www.cyewin.com/cyewin-ug-net/ntsec.html 


3.4 Windows 下 安装 和 使 用 Git (msysGit 篇 ) 


运行 在 Cygwin 下 的 Git 不 直接 使 用 Windows 的 系统 调用 ， 而 是 通过 
二 传 手 cygwin1.dl 来 进行 的 。 虽 然 Cygwin 中 的 Git 能 够 在 Windows 下 的 
cmd.exe 命 令 窗口 中 运行 良好 ， 但 Cygwin 下 的 Git 并 不 能 被 看 作 是 
Windows 下 的 原生 程序 。 相 比 Cygwin 下 的 Git，msysGit 才 是 原生 的 
Windows 程 序 ，msysGit 下 运行 的 Git 是 直接 通过 Windows 的 系统 调用 来 





运行 的 。 


msysGit 名 字 前 面 的 四 个 字母 来 源 于 MSYS 1 项目 。MSYS 项 目 源 自 
于 MinGW 1 (Minimalist GNU for Windows， 最 简 GNU 工 具 集 ) ， 通 过 
增加 一 个 bash 提 供 的 shell 环 境 及 其 他 相关 的 工具 软件 组 成 了 一 个 最 简 系 
统 (Minimal SYStem) ， 简 称 MSYS。 利 用 MinGW 提 供 的 工具 和 Git 针 
对 MinGW 的 一 个 分 支 版 本 ， 在 Windows 平 台 为 Git 编 译 出 一 个 原生 应 


用 ， 结 合 MSYS 束 组 成 了 msysGit。 
3.4.1 ”安装 msysGit 
安装 msysGit 非 党 简单， 访问 msysGit 的 项 目 主页 


《http://code.google.com/p/msysgit/ ) ， 下 载 msysGit。 最 简单 的 方式 是 
下 载 名 为 Git-<VERSION>-preview<DATE>.exe 的 软件 包 ， 如 Git-1.7.3.1- 


preview20101002.exe。 如 果 您 有 时 间 和 耐心 ， 想 观察 Git 是 如 何在 
Windows 上 被 编译 为 原生 应 用 的 ， 也 可 以 下 载 带 msysGit-fullinstall- 前 绥 
的 软件 包 。 


点 击 安装 程序 (如 Git-1.7.3.1-preview20101002.exe) 开始 安装 ， 如 
图 3-18 所 示 。 





aISi1xl 
Welcome to the Git Setup Wizard 









This will install Git version 1,7,3,1-preview20101002 on your 
computer, 


Itisrecommended that you close all other applications before 
continuing, 


Click Next to continue, or Cancel to exit Setup, 





图 3-18 启动 msysGit 安 装 


默认 安装 到 C:\Program Files\Git 目 录 中 ， 如 图 3-19 所 示 。 





在 安装 过 程 中 会 询问 是 否 修改 环境 变量 ， 如 图 3-20 所 示 。 默 认 选 
择 “Use Git Bash Only”， 即 只 在 msysGit 提 供 的 shell 环 境 ( 类 似 Cygwin) 
中 使 用 Git， 不 修改 环境 变量 。 注 意 ， 如 果 选 择 最 后 一 项 ， 会 将 msysGit 
所 有 的 可 执行 程序 全 部 加 入 Windows 的 PATH 路 径 中 ， 有 的 命令 会 覆盖 

















Windows 相 同文 件 名 的 程序 (如 find.exe 和 sort.exe) 。 而 且 ， 如 果 选 择 
最 后 一 项 ， 还 会 为 Windows 添 加 HOME 环境 变量 ， 如 果 安 装 有 Cygwin， 
Cygwin 就 会 受到 msysGit 引 入 的 HOME 环境 变量 的 影响 〈 参 见 前 面 3.3.3 
节 的 相关 讨论 ) 。 

EEC 二 


Select Destination Location 
Where should Git be installed? 


Ly Setup will install Git into the following folder, 


To continue, click Next, IF you would like to select a different folder, click Browse， 


| "\Program Files\Git Browse,,, | 


At least 56,9 MB of free disk space is required, 





< Back Cancel | 





图 3-19 ”选择 msysGit 的 安装 目录 


Git Setup 各 


Adjusting your PATH environment 
How would you like to use Git from the command line? 


GI+E 


Sesntetetet mentetettntnttttat etttatatttttesss 


人 Use Git Bash only 


rn 


This is the most conservative choice if you are concerned about the stabilty 
of your system, Your PATH will not be modified, 
六 Run Git from the Windows Command Prompt 


This option is considered safe and no conflicts with other tools are known, 
Only Git will be added to your PATH, Use this option if you want to use Git 
from a Cygwin Prompt (make sure to not have Cygwin's Git installed), 


人 Run Git and included Unix tools from the Windows Command Prompt 
Both Git and its accompanying Unix tools will be added to your PATH, 


Warning: This will override Windows tools like find.exe and 
sort.exe. Select this option only if you understand the implications. 


httpy/msysait aooglecodecorn) 


< Ca 





图 3-20 “是否 修改 系统 的 环境 变量 


还 会 询问 换行 符 的 转换 方式 ， 使 用 默认 设置 束 可 以 了 ， 如 图 3-21 所 
示 。 关 于 换行 符 转 换 的 内 容 ， 请 参见 本 书 第 8 篇 的 相关 音节 。 





Configuring the line ending conversions 
How should Git treat line endings in text files? 5 


PTT TT 


earnsrstnnnnssttnn nttitssstitis itis sits tits isttn iis. mrt.ssssrssm0msmms0tsus 上 ction 


Git will convert LF to CRLF when checking out text files, When committing 
text Files, CRLF will be converted to LF, For cross-platform projects, 
this is the recommended setting on Windows ("core,autocrlf" is set to "true"), 


人 Checkout as-is, commit Unix-style line endings 


Git will not perform any conversion when checking out text files, When 
committing text files, CRLF will be converted to LF, For cross-platform projectk: 
this is the recommended setting on Unix ("core,autocrlf" is set to "input"™, 


人 Checkout as-is, commit as-is 


Git will not perform any conversions when checking out or committing 
text files, Choosing this option is not recommended for cross-platform 
projects (core,autocrlF is set to "false", 


httpyimsysat aqooalecode, co 


< Back Cancel | 





图 3-21 ”换行 符 转 换 方式 
根据 提示 完成 msysGit 的 安装 。 
3.4.2 ”msysGit 的 配置 和 使 用 


完成 msysGit 的 安装 后 ， 点 击 Git Bash 图 标 ， 启 动 msysGit， 如 图 3- 
22。 会 发 现 Git Bash 的 界面 和 和 Cygwin 的 非常 相像 。 


二 MINGW32:fc/Documents and Settingsyjiangxin 和 和 


Welcome to Git (version 1.7.3.1-preview20101002) 


‘git help git' to display the help index. 
“git help 《command>” to display help for specific commands. 


Ss 
1.0.12(0.46/3/2) 


$ 








图 3-22 ”启动 Git Bash 
1. 如 何 访问 Windows 的 盘 符 


在 msysGit 下 访问 Windows 的 各 个 盘 符 要 比 Cygwin 人 简单， 直接 通 
过 “ce” 即 可 访问 Windows 的 C 和 可， 用 “%/d” 即 可 访问 Windows 的 DD 可。 





$ ls -ld /c/Windows 
drwxr-xr-x 233 jiangxin Administ 0 Jan 31 00:44 /c/Windows 





msysGit 的 根 目录 实际 上 就 是 msysGit 的 安装 目录 ， 如 “C:\Program 
Files\Git”。 


2. 命 令 行 补 齐 和 忽略 文件 大 小 写 


msysGit 默 认 已 经 安装 并 局 用 了 Git 的 命令 行 补 齐 功能 ， 是 通过 在 文 
件 /etc/profile 中 加 载 相 应 的 脚本 实现 的 。 





, /etc/git-completion.bash 


msysGit 还 文 持 在 命令 行 补 齐 时 忽略 文件 名 的 大 小 号， 这 是 因为 
msysGit 己 经 在 配置 文件 /etc/inputrc 中 包含 了 下 列 的 设置 : 





set completion-ignore-case on 





3.4.3 ”msysGit 中 shell 环 境 的 中 文 支持 


在 介绍 Cygwin 时 曾经 提 到 过 ，msysGit 的 shell 环 境 的 中 文 支持 情况 
与 老 版 本 的 Cygwin 5 类 似 ， 需 要 配置 才能 够 录入 中 文 和 显示 中 文 。 





1. 中 文 录入 问题 


默认 安装 的 msysGit 的 shell 环 境 中 无 法 输入 中 文 。 为 了 能 在 shell 界 面 
中 输入 中 文 ， 需 要 修改 配置 文件 /etwinputrc， 增 加 或 修改 相关 的 配置 如 
这 





# disable/enable 8bit input 
set meta-flag on 

set input-meta on 

set output-meta on 

set convert-meta off 





关闭 Git Bash 再 重启 ， 就 可 以 在 msysGit 的 shell 环 境 中 输入 中 文 了 。 





$ echo 您 好 
您 好 





2. 分 页 占 中 文 输出 问题 


对 /etc/inputrc 进 行 正 确 的 配置 之 后 就 能 够 在 shell 环 境 下 输入 中 文 
了 ， 但 是 执行 下 面 的 命令 时 会 显示 乱码 。 这 显然 是 less 分 页 占 命 令 导 致 
的 问题 。 





$ echo 您 好 | less 
<C4><FA><BA><C3> 





通过 管道 符 调用 分 页 器 命令 less 后 ， 原 本 的 中 文 输出 变 成 了 乱码 显 
示 。 因 为 Git 使 用 了 大 量 的 less 命 令 作 为 分 页 器 ， 这 导致 Git 的 很 多 命令 的 
输出 都 出 现 了 中 文 乱码 的 问题 。 之 所 以 less 命 令 会 导致 出 现 乱码 ， 是 因 
为 该 命令 没有 把 中 文 当 作 正 常 的 字符 ， 可 以 通过 设置 LESSCHARSET 坏 
境 变量 将 UTF-8 编 码 字符 视 为 正常 的 字符 ， 于 是 中 文 就 能 正常 显示 了 。 
下 面 的 操作 可 以 使 less 分 页 器 中 的 中 文正 常 显示 : 











$ export LESSCHARSET=utf-8 
$ echo 您 好 | less 
你 





编辑 配置 文件 /etc/profile， 将 对 环境 变量 LESSCHARSET 的 设置 加 
入 其 中 ， 以 便于 msysGit 的 shell 环 境 启 动 时 就 加 载 。 





declare -x LESSCHARSET=utf-8 





3.]sWi 令 显 不 中 文 久 件 御 





最 钊 用 的 用 于 显示 目录 和 文件 名 列表 的 命令 ls 在 显示 中 文 文件 名 的 
时 候 也 有 问题 。 下 面 的 命令 创建 了 一 个 中 文 名 称 的 文件 ， 文 件 内 容 中 的 
中 文 在 显示 时 没有 问题 ， 但 是 文件 名 却 显示 为 一 串 问 号 。 








$ echo 您 好 > 您 好 ,txt 
$ cat \*.txt 
您 好 





实际 上 ， 只 要 在 ls 命令 后 添加 参数 --show-control-chars 即 可 正确 显示 
中 文 : 





$ 1s --show-control-chars *.txt 
您 好 .txt 





为 方便 起 见 ， 可 以 为 ls 命令 设置 一 个 别名 ， 这 样 就 不 必 在 输入 ls 命 
令 时 输入 长 长 的 参数 了 。 





$ alias ls="ls --show-control-chars" 
$ ls \*.txt 
您 好 .txt 











将 上 面 的 alias 命 令 添 加 到 配置 文件 /etc/profile 中 ， 可 实现 在 每 次 运 
行 Git Bash 时 自动 加 载 。 


3.4.4 masysGit 中 Git 的 中 文 文 持 


非常 遗憾 的 是 ，msysGit 中 的 Git 对 中 文 支 持 不 如 Cygwin 中 的 Git， 


msysGit 中 的 Git 对 中 文 的 文 持 情 况 与 前 面 讨 论 过 的 使 用 了 GBK 字 符 集 的 
Linux 环 境 下 的 Git 相 当 。 


(1) 使 用 未 经 配置 的 msysGit 提 交 ， 如 果 提 交 说 明 中 包含 中 文 ， 从 
Linux 平 台 或 其 他 UTF-8 字 符 集 平台 上 查看 提交 说 明 时 会 显示 为 乱码 。 


(2) 同样 ， 从 Linux 平 台 或 其 他 使 用 UTF-8 字 符 集 平台 进行 的 提 
交 ， 若 提交 说 明 包含 中 文 ， 在 未 经 配置 的 msysGit 中 也 会 显示 为 乱码 。 





(3) 如 果 使 用 msysGit 同 版 本 库 中 添加 带 有 中 文 文件 名 的 文件 ， 在 
Linux (或 其 他 UTF-8) 平台 检 出 文件 名 时 会 显示 为 乱码 ， 反 之 亦 然 。 


(4) 不 能 创建 带 有 中 文字 符 的 引用 《里 程 碑 和 分 文 等 ) 。 


如 果 希 望 版 本 库 中 出 现 使 用 中 文 文件 名 的 文件 ， 最 好 不 要 使 用 
msysGit， 而 应 该 使 用 Cygwin 下 的 Git。 如 果 只 是 想 在 提交 说 明 中 使 用 中 
文 ， 对 msysGit 进 行 一 定 的 设置 后 还 是 可 以 实现 的 。 


为 了 解决 提交 说 明显 示 为 乱码 的 问题 ，msysGit 要 为 Git 设 置 参数 
i18n.logOutputEncoding， 将 提交 说 明 的 输出 编码 设置 为 gbk: 


$ git config --system i1i8n.logOutputEncoding gbk 


Git 在 提交 时 并 不 会 对 提交 说 明 进 行 从 GBK 字 符 集 到 UTF-8 字 符 集 的 
转换 ， 但 是 可 以 在 提交 说 明 中 标注 所 使 用 的 字符 集 。 因 此 ， 如 果 在 非 


UTF-8 字 符 集 的 平台 中 录入 中 文 ， 需 要 用 下 面 的 指令 设置 录入 提交 说 明 
的 字符 集 ， 以 便 在 commit 对 象 中 磐 入 正确 的 编码 说 明 。 





$ git config --system ii8n.commitEncoding gbk 





同样 ， 为 了 让 带 有 中 文 文件 名 的 文件 在 工作 区 状态 输出 、 查 看 历史 
更 改 概 要 ， 以 及 在 补丁 文件 中 能 够 正常 显示 ， 要 为 Git 设 置 core.quotepath 
配置 变量 ， 将 其 设置 为 false。 但 是 要 注意 ， 如 果 在 msysGit 中 添加 文件 
名 包含 中 文 的 文件 ， 就 只 能 在 msysGit 环 境 中 正确 显示 ， 而 在 其 他 环境 
(如 Linux、Mac OS X、Cygwin) 中 文件 名 会 显示 为 乱码 。 











$ git config --system core.quotepath false 
$ git status -s 
?3 说 明 .txt 





注意 ”如 果 同 时 安装 了 Cygwin 和 msysGit (可 能 配置 了 相同 的 用 户 
主 目录 ) ， 或 者 因为 中 文 支持 问题 而 需要 单独 为 TortoiseGit 准 备 一 套 
msysGit 时 ， 为 了 保证 不 同 的 msysGit 之 间 ， 以 及 与 Cyewin 之 间 的 配置 互 
不 影响 ， 需 要 在 配置 Git 环 境 时 使 用 --system 参 数 。 这 是 因为 不 同 的 
msysGit 安 装 及 Cygwin 的 系统 级 配置 文件 的 位 置 不 同 ， 但 是 用 户 级 配置 文 
件 的 位 置 却 可 能 重合 。 


3.4.5 ”使 用 SSH 人 协议 


msysGit 软 件 包 包含 的 ssh 命 令 和 Linux 下 的 ssh 命 令 没 有 什么 区 别 ， 
也 提供 ssh-keygen 命 令 管理 SSH 公 钥 / 私 钥 对 。 在 使 用 msysGit 的 ssh 命 令 
时 ， 没 有 遇 到 Cygwin 中 的 ssh 命 令 〈 版 本 号 : 5.7p1-1) 不 稳定 的 问题 ， 
即 msysGit 下 的 ssh 命 令 可 以 非常 稳定 地 工作 。 





如 果 需 要 与 Windows 更 好 地 整合 ， 和 希望 使 用 图 形 化 工具 管理 公 钥 ， 
也 可 以 使 用 PuTTY 提 供 的 plink.exe 作 为 SSH 客 户 端 。 关 于 如 何 使 用 
PuTTY， 请 参见 3.3.5 节 中 Cygwin 和 PuTTY 整 合 的 相关 内 容 。 





3.4.6 ”TortoiseGit 的 安装 和 使 用 


TortoiseGit 可 以 让 Git 与 Windows 资 源 管 理 器 进行 整合 ， 为 Git 提 供 了 
图 形 化 操作 界面 。 像 其 他 Tortoise 系 列 产品 〈TortoiseCVS、 
TortoiseSVN ) 一 样 ， 在 资源 管理 器 中 显示 的 Git 工 作 区 目录 和 文件 的 图 
标 附加 了 标识 版 本 控制 状态 的 图 像 ， 这 样 可 以 非常 直观 地 看 到 哪些 文件 
被 更 改 了 并 需要 提交 。 通 过 扩展 后 的 右键 菜单 ， 可 以 非常 方便 地 在 资源 
管理 桌 中 操作 Git 版 本 库 。 














TortoiseGit 是 对 msysGit 命 令 行 的 封装 ， 因 此 需要 先 安装 msysGit。 
安装 TortoiseGit 非 常 简单 ， 访 问 网 站 http://code.google.com/p/tortoisegit/ 
， 下 载 安装 包 ， 然 后 根据 提示 完成 安装 。 





安装 过 程 中 会 询问 要 使 用 的 SSH 客 户 端 ， 如 图 3-23， 默 认 使 用 内 置 


的 TortoisePLink (来 自 PuTTY 项 目 ) 作为 SSH 客 户 端 。 





食 TortoiseGit 1.6.3.0 (32 bit) Setup X| 


Choose SSH Client 
Choose a kind of 55H Client 








{* TortoisePLink, coming from Putty, integrates with Windows better, 


© Open55H, Git default 55H Client 





Cancel | 








图 3-23 ”选择 3SH 客 户 端 





TortoisePLink 和 和 TortoiseGit 的 整合 性 更 好 ， 可 以 直接 通过 对 话 框 设 
置 SSH 私 钥 (PuTTY 格 式 ) ， 而 无 顷 再 到 字符 界面 去 配置 SSH 私 铀 和 其 
他 配置 文件 。 如 果 安 装 过 程 中 选择 了 OpenSSH， 可 以 在 安装 完 之 后 通过 
TortoiseGit 的 设置 对 话 框 重新 选择 TortoisePLink 作 为 默认 SSH 客 户 端 ， 

如 图 3-24 所 示 。 





Network 








图 3-24 ”更改 默认 SSH 客 户 端 


当 使 用 TortoisePLink 作 为 默认 的 SSH 客 户 端 后 ， 在 执行 克隆 操作 
时 ， 可 以 在 TortoiseGit 操 作 界 面 中 选择 一 个 PuTTY 格 式 的 私 钥 文件 进行 
认证 ， 如 图 3-25 所 示 。 


RB Git clone ” x| 


Clone Existing Repository 






DD qt@bj,ossxp,com:users/jiangxinjwindows ,git 


Directory: P: VWwork\tgit-test wse | 


三 depth Pp 厂 Clone into Bare Repo 


lV Load Putty Key 仿 C:\Documents and Settings\jiangxin\jiangxin,ppk ”| i | 


From SYN Repository 
From SYN Repository 


runk Frurk FF T565 ltags 厂 Branch ranches 
Erom F Usernarne | 





图 3-25 ”克隆 操作 选择 PuTTY 格 式 的 私 钥 文件 


如 果 需 要 更 换 连 接 服 务 器 的 SSH 私 钥 ， 可 以 通过 Git 远 程 服 务 器 配置 
界面 对 私 钥 文 件 进行 重新 设置 ， 如 图 3-26 所 示 。 


加 
日 -六 General -~、 Config - DWorkitgittest DD 





Context Menu 


Set Extend Menu Item 





ER Remote: 
po Dialogs 1 
pee Nemo ron ，，，，，， 
Colors 1 
YY Colors 2 Url: [ait@bi.ossxp.com:usersiiiangxinfwindows 
Colors 3 

Ee Overlays Putty Key: [Toe mE 

全 3 Icon Set 
名 Network 

日 -全 External Programs 
QQ Diff Viewer Add New 
Y¥ Merge Tool _agdNew | 
入 Unified Diff Viewer 

党 Saved Data _ Remove | 

已 夸 Git 
碟 、 Config 
访 Remote 

© Hook Scripts 
毒 Issue Tracker Integration 
毒 Issue Tracker Config 


i | 2 


全 TortoiseBlame 





图 3-26 更换 连接 远程 SSH 服 务 器 的 私 钥 


如 果 系 统 中 安装 有 多 个 msysGit 的 拷贝 ， 可 以 通过 TortoiseGit 的 配置 
界面 进行 选择 ， 如 图 3-27 所 示 。 


Vr Settings - TortoiseGit 和 Xx| 
SR ere 


Context Menu 





























Set Extend Menu Item TortoiseGit 
A Dialogs 1 ode 
A Dialogs 2 k En 
Colors 1 > 
ED IY Automatically check for newer versions every week Check now | 
Colors 3 Cuoreb pe ~ a a PS 
8 Icon Overlays 3 用 | 
3 Icon Set 
© Network 
日 -路 External Programs | MSysGRt 
QQ, DIF Viewer 





， Path; Cc'\Prooram Files\Git\bir mr 
Y Merge Tool Git,exe Path er ee | 


,Unified Diff Viewer 


篇 5avedData Extern DLL Path; | 


日 -起 Git 
AR Config Yersion: Check now | 
Remote 

Be Hook Scripts 

毒 Issue Tracker Integration 
闭 155ue Tracker Config 
包 TortoiseBlame 











图 3-27 配置 msysGit 的 可 执行 程序 位 置 


3.4.7 ”TortoiseGit 的 中 文 支持 


虽然 TortoiseGit 在 底层 调用 了 msysGit， 但 是 TortoiseGit 的 中 文 支持 
与 msysGit 是 有 区 别 的 。 前 面 在 介绍 msysGit 的 中 文 支持 时 所 进行 的 配制 
会 破坏 TortoiseGit。 


TortoiseGit 在 提交 时 会 将 提交 说 明 转 换 为 UTF-8 字 符 集 ， 因 此 无 须 
对 i18n.commitEncoding 变 量 进行 设置 。 相 反 ， 如 果 将 
il8n.commitEncoding 设 置 为 gbk 或 其 他 字符 集 ， 则 在 提交 对 象 中 会 包含 


错误 的 编码 设置 ， 有 可 能 会 给 提交 说 明 的 显示 带 来 采 烦 。 


TortoiseGit 在 显示 提交 说 明 时 认为 所 有 的 提交 说 明 都 是 UTF-8 编 
码 ， 会 转换 为 合适 的 Windows 本 地 字符 集 显示 ， 而 无 须 设 置 
i18n.logOutputEncoding 变 量 。 因 为 当前 版 本 的 TortoiseGit 没 有 对 提交 对 
象 中 的 encoding 设 置 进行 检查 ， 所 以 使 用 GBK 字 符 集 的 提交 说 明 中 的 中 


文 不 能 正常 显示 。 








此 ， 如 果 需 要 同时 使 用 msysGit 的 文字 界面 Git Bash 和 
TortoiseGit， 而 且 和 需要 在 提交 说 明 中 使 用 中 文 ， 可 以 安装 两 套 msysGit， 
并 确保 TortoiseGit 关 联 的 msysGit 没 有 对 i18n.commitEncoding 进 行 设置 。 





与 msysGit 一 样 ，TortoiseGit 对 使 用 中 文 命名 的 文件 和 目录 的 支持 ， 
也 存在 缺陷 ， 因 此 应 当 避 免 在 msysGit 和 TortoiseGit 中 添加 用 中 文 命名 的 
文件 和 目录 ， 如 果 确 实 需要 ， 可 以 使 用 Cygwin。 





[1] http:/ /www.mingw.org/ wiki/msys 
[2] http:/ /www.mingw.org/ 
[3] MSYS 是 源 自 于 Cygwin1.3 的 轻 量 级 分 支 (参考 


http:/ /www.mingw.org/ ) 


第 2 篇 ”Git 独 奏 


从 本 篇 开始 ， 我 们 就 真正 地 进入 到 Git 的 学 习 中 。Git 有 着 陡 蚜 的 学 
习 曲 线 ， 对 有 其 他 版 本 控制 工具 使 用 经 验 的 老手 也 不 例外 ， 因 为 他 们 有 
可 能 会 按照 在 其 他 版 本 控制 系统 中 遗留 的 习惯 去 操作 Git， 努 力 地 在 Git 
中 寻找 对 应 物 ， 最 终 会 因为 Git 的 “别扭 * 而 放弃 使 用 ， 这 也 是 我 的 杀 冉 经 
历 。 





Git 的 “别扭 * 部 分 源 自 于 传统 的 集中 式 版 本 控制 系统 与 以 Git 为 代表 
的 分 布 式 版 本 控制 系统 在 理念 上 的 巨大 差异 ， 部 分 是 因为 其 设计 者 
Linus Torvalds 对 Git 独 特 的 创新 式 设计 。“ 你 应 该 了 解 真 相 ， 真 相 会 使 你 
自由 ” 趾 ， 因 此 本 书 会 将 Git 的 设计 原理 渗透 到 每 一 个 章节 ， 让 您 通过 不 
断 地 实践 、 思 考 、 再 实践 来 循序 渐进 地 掌握 Git。 








本 篇 暂时 不 会 涉及 团队 如 何 使 用 Git 的 内 容 ， 而 是 先 从 个 人 的 角度 
去 探讨 如 何 用 好 Git。 本 篇 是 全 书 最 重要 的 部 分 ， 是 下 一 步 进 行 团队 协 
作 必 需 的 知识 准备 ， 也 是 理解 全 书 其 余 各 部 分 内 容 的 基础 。 到 本 篇 的 结 
尾 时 ， 我 们 会 发 现 通 过 “Git 独 奏 ” 也 可 以 演绎 出 美妙 的 “乐曲 ”。 


[11] 圣经 《约翰 福音 8:32》 。 


第 4 章  Git 初 始 化 
4.1 创建 版 本 库 及 第 一 次 提交 


您 当前 使 用 的 Git 是 1.5.6 版 或 更 高 的 版 本 吗 ? 通过 如 下 操作 来 查看 
一 下 您 的 Git 版 本 : 
$ git --version 
git version 1.7.4 
Git 是 一 个 活跃 的 项 目 ， 仍 在 不 断 地 进化 之 中 ， 不 同 版 本 的 Git 功 能 
不 尽 相 同 。 本 书 对 Git 的 介绍 涵盖 了 1.5.6 到 1.7.4 版 本 ， 这 也 是 目前 Git 的 
主要 版 本 。 如 果 您 使 用 的 Git 版 本 低 于 1.5.6， 那 么 请 升级 到 1.5.6 或 更 高 
的 版 本 。 本 书 示 例 使 用 的 是 1.7 版 本 的 Git， 我 们 会 尽 可 能 地 指出 那些 与 
低 版 本 不 兼容 的 命令 及 参数 。 











在 开始 Git 之 旅 之 前 ， 我 们 需要 设置 一 下 Git 的 配置 变量 ， 这 是 一 次 
性 的 工作 。 即 这 些 设 置 会 在 全 局 文件 〈 用 户主 目录 下 的 .gitconfig) 或 系 
统 文件 〈 如 /etc/gitconfig) 中 做 永久 的 记录 。 


(1) 告诉 Git 当 前 用 户 的 姓名 和 邮件 地 址 ， 配 置 的 用 户 名 和 邮件 地 
址 将 在 版 本 库 提交 时 用 到 。 


注意 ， 不 要 照抄 照搬 下 面 的 两 条 命令 ， 而 是 用 您 自己 的 用 户 名 和 邮 
件 地 址 代替 这 里 的 用 户 名 和 邮件 地 址 ， 和 否则 您 的 劳动 成 果 《〈 提 交 内 容 ) 
可 就 要 算 到 我 的 兴 上 了 。 





$ git config --global user.name "Jiang Xin" 
$ git config --global user.email jiangxin@ossxp.com 





(2) 设置 一 些 Git 别 名 ， 以 便 可 以 使 用 更 为 简洁 的 子 命令 。 
例如 : 输入 git ci 即 相 当 于 git commit， 输 入 git st 即 相 当 于 git status。 


如 果 拥 有 系统 管理 员 权 限 《“ 例 如 通过 执行 sudo 命令 获取 管理 员 权 
限 ) ， 和 希望 注册 的 命令 别名 能 够 被 所 有 用 户 使 用 ， 可 以 执行 如 下 命令 : 





$ sudo git config --system alias.st status 
$ sudo git config --system alias.ci commit 
$ sudo git config --system alias.co checkout 
$ sudo git config --system alias.br branch 








也 可 以 运行 下 面 的 命令 ， 只 在 本 用 户 的 全 局 配置 中 添加 Git 命 令 别 
名 : 





$ git config --global alias.st status 
$ git config --global alias.ci commit 
$ git config --global alias.co checkout 
$ git config --global alias.br branch 





(3) 在 Git 命 令 输 出 中 开启 颜色 显示 。 





$ git config --global color.ui true 





Git 的 所 有 操作 ， 包 括 创建 版 本 库 等 管理 操作 用 git 一 个 命令 即 可 完 
成 ， 不 像 其 他 版 本 控制 系统 〈 如 Subversion) ， 与 管理 相关 的 操作 要 使 
用 为 外 的 命令 (如 svnadmin〉。 创 建 Git 版 本 库 ， 可 以 直接 进入 到 工作 目 
录 中 ， 通 过 执行 git init 命 令 完 成 版 本 库 的 初始 化 。 








下 面 就 从 一 个 空 目 录 开 始 初始 化 版 本 库 ， 将 这 个 版 本 库 命 名 
为 "DEMO 版 本 库 ?， 这 个 DEMO 版 本 库 将 贯穿 本 篇 始终 。 为 了 方便 说 
明 ， 我 们 使 用 名 为 /path/to/my/workspace 的 目录 作为 个 人 的 工作 区 根 目 
录 ， 可 以 在 磁盘 中 创建 该 目录 并 设置 正确 的 权限 。 





首先 建立 一 个 新 的 工作 目录 ， 进 入 该 目录 后 ， 执 行 git init 创 建 版 本 
2 


$ cd /path/to/my/workspace 

$ mkdir demo 

$ cd demo 

$ git init 

Initialized empty Git repository in /path/to/my/workspace/demo/ .git/ 


实际 上 ， 如 果 Git 的 版 本 是 1.6.5 或 更 新 的 版 本 ， 可 以 在 git init 命 令 的 
后 面 直接 输入 目录 名 称 ， 自 动 完成 目录 的 创建 。 











$ cd /path/to/my/workspace 

$ git init demo 

Initialized empty Git repository in /path/to/my/workspace/demo/ .git/ 
$ cd demo 


从 上 面 版 本 库 初 始 化 后 的 输出 中 可 以 看 到 ，git init 命 令 在 工作 区 创 


建 了 隐藏 目录 .git。 


$ ls -aF 
./ ../ .git/ 





这 个 隐藏 的 .git 目 录 束 是 Git 碑 本 库 〈 又 叫 仓库 ，repository) 。 


.git 版 本 库 所 在 的 目录 为 /path/to/my/workspace/demo， 它 被 称 为 工作 
， 目 前 工作 区 除了 包含 一 个 隐藏 的 .git 版 本 库 目 录 外 空 无 一 物 。 


区 | 


下 面 为 工作 区 中 加 点 料 : 在 工作 区 中 创建 一 个 文件 welcome.txt， 内 
就 是 一 行 “Hello.”。 


$ echo "Hello." > welcome.txt 











为 了 将 这 个 新 建立 的 文件 添加 到 版 本 库 ， 需 要 执行 下 面 的 命令 : 


$ git add welLcome ,txt 


注意 ， 到 这 里 还 没有 完 。Git 和 大 部 分 其 他 版 本 控制 系统 一 样 ， 痢 
需要 再 执行 一 次 提交 操作 ， 对 于 Git 来 说 就 是 执行 git commit 命 令 完 成 提 
交 。 在 提交 过 程 中 需要 输入 提交 说 明 ， 这 个 要 求 对 于 Git 来 说 是 强制 性 
的 ， 不 像 其 他 很 多 版 本 控制 系统 (如 CVS 和 Subversion〉 那 样 接受 空白 
的 提交 说 明 。 当 Git 提 交 时 ， 如 果 不 在 命令 行 提供 提交 说 明 使 用 -m 参 
数 ) ，Git 会 目 动 打开 一 个 编辑 器 ， 要 求 您 在 其 中 输入 提交 说 明 ， 和 输入 








完毕 后 保存 并 退出 。 需 要 说 明 的 是 ， 读 者 要 在 一 定 程度 上 和 掌握 vim 或 
emacs (Linux 下 常用 的 两 种 编辑 器 ) 的 编辑 技巧 ， 和 否则 保存 和 退出 也 会 
成 为 问题 。 





下 面 进行 提交 。 为 了 说 明 方 便 ， 使 用 -mm 参数 直接 给 出 了 提交 说 明 。 





$ git ci -m "initialized." 

[master (root-commit) 78cde45] initialized. 

1 files changed, 1 insertions(+), 0 deletions(-) 
create mode 100644 welcome.txt 





从 上 面 的 命令 及 输出 中 可 以 看 出 : 


` 命令 git ci 实际 上 相当 于 git commit， 这 是 因为 之 前 为 Git 设 置 了 命 


` 通过 -m 参 数 设置 提交 说 明 为 : “initialized.”。 


从 命令 输出 的 第 一 行 可 以 看 出 ， 此 次 提交 是 提交 在 名 为 mastet 的 
分 支 上 ， 且 是 该 分 支 的 第 一 个 提交 (root-commit) ， 提 交 ID 为 78cde45 


加 


O 


. 从 命令 输出 的 第 二 行 可 以 看 出 ， 此 次 提交 修改 了 一 个 文件 ， 包 含 


一 行 的 插 入 。 


从 命令 输出 的 第 三 行 可 以 看 出 ， 此 次 提交 创建 了 新 文件 


welcome.txt。 


上 大 家 实际 操作 中 看 到 的 ID 肯 定 和 这 里 写 的 不 一 样 ， 有 具体 原因 会 在 后 
面 的 6.1 节 中 予以 介绍 。 如 果 碰 巧 您 的 操作 也 显示 出 了 同样 的 
ID (78cde45) ， 那 么 我 建议 您 赶紧 去 买 一 张 彩 票 。 


4.2 思考 : 为 什么 工作 区 根 目 录 下 有 一 个 .git 目 录 


Git 及 其 他 分 布 式 版 本 控制 系统 (如 Mercurial/Hg、Bazaar)〉 的 一 个 
共同 的 显著 特点 是 ， 版 本 库 位 于 工作 区 的 根 目录 下 。 对 于 Git 来 说 ， 版 
本 库 位 于 工作 区 根 目 录 下 的 .git 目 录 中 ， 且 仅 此 一 处 ， 在 工作 区 的 子 目 
录 下 则 没有 任何 其 他 跟踪 文件 或 目录 。Git 的 这 种 设计 要 比 CVS 和 
Subversion 等 传统 的 集中 式 版 本 控制 工具 方便 多 了 。 








传统 的 集中 式 版 本 控制 系统 的 版 本 库 和 工作 区 是 分 开 的 ， 其 至 是 在 
不 同 的 主机 上 上， 因此 必须 建立 工作 区 和 版 本 库 的 对 应 。 下 面 来 看 看 版 本 
控制 系统 的 前 非 们 是 如 何 建立 工作 区 和 版 本 库 的 跟 躁 的， 通过 其 各 目 设 
计 的 优 缺 点 ， 我 们 会 更 深刻 地 体会 到 Git 实 现 的 必要 和 巧妙 。 











对 于 CVS 而 言 ， 工 作 区 的 根 目录 及 每 一 个 子 目 录 下 都 有 一 个 CVS 目 
录 ，CVS 目 录 中 包含 几 个 配置 文件 ， 建 立 了 对 版 本 库 的 退 中 。 如 CVS 有 目 
录 下 的 Entries 文 件 记 录 了 从 版 本 库 检 出 到 工作 区 的 文件 的 名 称 、 版 本 和 
时 间 戳 等， 通过 时 间 惟 的 对 比 可 快速 扫描 工作 区 文件 的 改动 。 这 样 设计 
的 好 处 是 ， 可 以 将 工作 区 移动 到 任何 其 他 目录 中 ， 而 工作 区 和 版 本 控制 
服务 器 的 映射 关系 保持 不 变 ， 这 样 工作 区 依然 能 够 正常 工作 。 甚 至 还 
以 将 工作 区 的 某 个 子 目录 移动 到 其 他 位 置 ， 形 成 新 的 工作 区 ， 在 新 的 工 
作 区 下 仍然 可 以 完成 版 本 控制 相关 的 操作 。 但 是 缺点 也 很 多 ， 例 如 ， 如 











果 工 作 区 文件 修改 了 ， 因 为 没有 原始 文件 做 比 对 ， 所 以 向 服务 器 提交 修 
改 时 只 能 对 整个 文件 进行 传输 ， 而 不 能 仅 传 输 文件 的 改动 部 分 ， 导 致 从 
客户 端 到 服务 器 的 网 络 传输 效率 降低 。 还 有 一 个 风险 是 信息 泄漏 ， 例 
如 ，Web 服 务 器 的 目录 下 如 果 包 含 了 CVS 目 录 ， 黑 客 就 可 以 通过 扫描 
CVS/Entries 文 件 得 到 目录 下 的 文件 列表 ， 从 而 获得 他 们 想 要 的 信息 。 








对 于 Subversion 来 说 ， 工 作 区 的 根 目录 和 每 一 个 子 目录 下 都 有 一 
个 .svn 目 录 。 目 录 .sSvn 中 不 仅 包 含 了 类 似 于 CVS 的 跟踪 目录 下 的 配置 文 
件 ， 而 且 包 含 了 当前 工作 区 下 每 一 个 文件 的 拷贝 。 这 些 文件 的 原始 拷贝 
让 某 些 SVN 子 命令 可 以 脱离 版 本 库 执行 。 而 且 ， 当 由 客户 端 向 服务 器 提 
交 时 ， 可 以 只 提交 改动 的 部 分 ， 因 为 改动 的 文件 可 以 与 文件 的 原始 拷贝 
进行 差异 比较 。 但 是 ， 这 么 做 也 有 缺点 ， 除 了 会 像 CVS 那 样 因为 引入 
CVS 跟 踪 目 录 而 有 可 能 造成 信息 泄漏 外 ， 还 会 加 倍 占用 工作 区 的 空间 。 
此 外 ， 当 在 工作 区 目录 下 针对 文件 内 容 进 行 搜 索 时 ， 会 因为 .svn 目 录 下 
文件 的 原始 拷贝 导致 搜索 结果 加 倍 ， 使 搜索 结果 混乱 。 























有 的 版 本 控制 系统 在 工作 区 根本 束 没 有 任何 跟 踩 文件， 例如， 茶 球 
商业 的 版 本 控制 软件 (就 不 点 名 了 )》 的 工作 区 就 非常 干净 ， 没 有 任何 配 
置 文件 和 配置 目录 。 但 是 ， 这 样 的 设计 更 糟糕 ， 因 为 它 实 际 上 是 通过 服 
务 句 端 建 并 文件 跟踪 ， 在 服务 占 端 的 数据 库 中 保存 了 一 个 包含 如 下 信息 
的 表格 : 哪个 客户 器 ， 在 哪个 本 地 目录 检 出 了 哪个 版 本 的 版 本 库 文 件 。 
这 样 做 的 后 果 是 ， 如 果 客 户 端 将 工作 区 移动 或 改名 ， 吏 会 导致 文件 的 跟 








踩 状 态 丢 失 ， 从 而 出 现 文 件 状态 未 知 的 问题 。 此 外 ， 客 户 端 操作 系统 重 
装 也 会 导致 文件 跟踪 状态 丢失 。 


Git 这 种 将 版 本 库 放 在 工作 区 根 目录 下 的 设计 使 得 所 有 的 版 本 控制 
操作 《除了 与 其 他 远程 版 本 库 之 间 的 互 操作 ) 都 在 本 地 即 可 完成 ， 不 像 
Subversion 只 有 冤 容 无 几 的 几 个 命令 脱离 网 络 执行 。 而 且 ，Git 没 有 CVS 
和 Subversion 中 存在 的 安全 泄漏 问题 〈 只 要 保护 好 .git 目 录 ) ， 也 不 会 像 
Subversion 那 样 在 搜索 本 地 文件 时 出 现 搜索 结 末 混乱 的 问题 。 甚 至 ，Git 
还 提供 了 一 条 git grep 命 令 来 更 好 地 搜索 工作 区 的 文件 内 容 ， 例 如 ， 我 们 
可 以 在 本 书 的 Git 库 中 执行 下 面 的 命令 来 搜索 版 本 库 中 的 文件 内 容 : 
































$ git grep "工作 区 文件 内 容 搜索 " 
02-git-solo/010-git-init.rst:`git grep” 命令 来 更 好 地 搜索 工作 区 的 文件 内 容 。 








Git 将 版 本 库 (.git 目 录 〉 放 在 工作 区 根 目录 下 ， 那 么 Git 的 相关 操作 
一 定 要 在 工作 区 根 目录 下 执行 吗 ? 换 句 话说 ， 当 工作 区 中 包含 子 目录 ， 
并 在 子 目录 中 执行 Git 命 令 时 ， 如 何 定位 版 本 库 呢 ? 











实际 上 ， 妆 在 Git 工 作 区 的 某 个 子 目录 下 执行 操作 的 时 候 ， 会 在 工 
作 区 目录 中 依次 同上 递归 碍 找 .git 目 录 ， 找 到 的 .git 目 录 就 是 工作 区 对 应 
的 版 本 库 ，.git 所 在 的 目录 就 是 工作 区 的 根 目录 ， 文 件 .giWindex 记 录 了 工 
作 区 文件 的 状态 《实际 上 是 暂 存 区 的 状态 ) 。 


例如 ， 在 非 Git 工 作 区 执行 git 命 令 时 会 因为 找 不 到 .git 目 录 而 报错 。 


$ cd /path/to/my/workspace/ 
$ git status 
fatal: Not a git repository (or any of the parent directories): .git 





如 果 用 strace 上 命令 去 跟踪 执行 git status 命 令 时 的 磁盘 访问 ， 会 看 到 
沿 目 录 依 次 癌 上 递归 的 过 程 。 





$ strace -e 'trace=file' git status 


getcwd("/path/to/my/workspace", 4096) = 14 

stat(".", {Sst_mode=S_IFDIR|0755， Sst_size=4096, ...})= 0 

stat(".git", QOx7fffdf1288d0) -1 ENOENT (No such file or directory) 
access(".git/objects", X_OK) -1 ENOENT (No such file or directory) 
access("./objects", X_OK) -1 ENOENT (No such file or directory) 
stat("..", {st_mode=S_ IFDIR|0755, Sst_size=4096, ...})= 0 

chdir("..") = 0 

stat(".git", 90x7fffdf1288d0 ) -1 ENOENT (No such file or directory) 
access(".git/objects", X_OK) -1 ENOENT (No such file or directory) 
access("./objects", X_OK) -1 ENOENT (No such file or directory) 


stat("..", {st_ mode=S_ IFDIR|0755, st_size=4096, ...})=0 

chdir("..") = 0 

stat(".git", 0x7fffdf1288d0 ) = -1 ENOENT (No such file or directory) 
access(".git/objects", X_OK) = -1 ENOENT (No such file or directory) 
access("./objects", X_OK) = -1 ENOENT (No such file or directory) 


fatal: Not a git repository (or any of the parent directories): .git 





当 在 工作 区 执行 Git 命 令 时 ， 上 面 但 找 版 本 库 的 操作 总 是 默默 地 执 
行 ， 束 好 像 什么 也 没有 发 生 一 样 。 那 么 有 什么 办 法 知道 Git 版 本 库 的 位 
置 呢 ? 如 何 才能 知道 工作 区 的 根 目录 在 哪里 呢 ? 可 以 用 Git 的 一 个 底层 
命令 来 实现 ， 具 体操 作 过 程 如 下 : 


(1) 在 工作 区 中 建立 目录 a/b/c， 进 入 到 该 目录 中 。 





$ cd /path/to/my/workspace/demo/ 
$ mkdir -p a/b/c 
$ cd /path/to/my/workspace/demo/a/b/c 








(2) 显示 版 本 库 .git 目 录 所 在 的 位 置 。 


$ git rev-parse --git-dir 
/path/to/my/workspace/demo/ .git 


(3) 显示 工作 区 根 目 录 。 


$ git rev-parse --git-dir 
/path/to/my/workspace/demo/ .git 


(4) 相对 于 工作 区 根 目录 的 相对 目录 。 


$ git rev-parse --show-prefix 
a/b/c/ 








(5) 显示 从 当前 目录 (cd) 后 退 Cup) 到 工作 区 的 根 的 深度 


$ git rev-parse --show-cdup 
AP A A 


传统 的 集中 式 版 本 控制 系统 的 工作 区 和 版 本 库 痢 是 相 分 离 的 ， 像 








Git 这 样 把 版 本 库 目 录放 在 工作 区 是 不 是 太 不 安全 了 ? 


从 存储 安全 的 角度 上 来 讲 ， 将 版 本 库 放 在 工作 区 目录 下 有 点 “把 鸡 





重 装 在 一 个 篮子 里 ”的 味道 。 如 果 瑟 记 了 工作 区 中 还 有 版 本 库 ， 当 直接 
从 工作 区 的 根 执行 目录 删除 操作 时 融会 连 版 本 库 一 并 删除 ， 这 个 风险 的 
确 很 高 。 将 版 本 库 和 工作 区 拆 开 似乎 更 加 安全 ， 但 是 不 要 还 了 之 前 的 讨 
论 ， 如 果 将 版 本 库 和 工作 区 拆 开 ， 束 要 引入 其 他 机 制 以 便 实现 版 本 库 对 





工作 区 的 追踪 。 





Git 克 隆 可 以 降低 因为 版 本 库 和 工作 区 混杂 在 一 起 而 导致 的 版 本 库 
被 破坏 的 风险 。 可 以 通过 克隆 操作 在 本 机 夯 外 的 磁盘 /目录 中 建立 Git 融 
隆 ， 并 在 工作 区 有 新 的 提交 时 ， 手 动 或 目 动 地 执行 网 克隆 版 本 库 的 推送 
(git push) 操作。 如 果 使 用 网 络 协 议 ， 还 可 以 实现 在 其 他 机 各 上 建立 殉 
隆 ， 这 样 就 更 安全 了 《〈 双 机 备份 ) 。 对 于 使 用 Git 做 版 本 控制 的 团队 ， 
每 个 人 都 是 一 个 备份 ， 因 此 团队 开发 中 的 Git 版 本 库 更 安全 ， 管 理 员 其 
至 无 须 顾 处 版 本 库存 储 的 安全 问题 。 











[1] Mac OS 又 可 以 使 用 dtruss 命 令 。 


4.3 思考 : git config 命 令 的 各 参数 有 何 区 别 


在 之 前 出 现 的 git config 命 令 中 ， 有 的 使 用 了 --global 参 数 ， 有 的 使 用 
了 -System 参 数 ， 这 两 个 参数 有 什么 区 别 吗 ? 执行 下 面 的 一 系列 命令 
后 ， 您 就 会 明白 使 用 不 同 参数 的 git config 命 令 实 际 操作 的 文件 了 。 


` 执行 下 面 的 命令 ， 将 打开 /path/to/my/wotkspace/demo/.git/config 


文件 进行 编辑 。 





$ cd /path/to/my/workspace/demo/ 
$ git config -e 





` 执行 下 面 的 命令 ， 将 打开 /home/jiangxin/.gitconfig (用 户主 目录 
下 的 .gitconfig 文 件 ) 全 局 配置 文件 进行 编辑 。 





$ git config -e --global 





` 执行 下 面 的 命令 ， 将 打开 /etc/gitconfig 系 统 级 配置 文件 进行 编 
辑 。 如 果 Git 安 装 在 非 标准 位 置 ， 则 这 个 系统 级 的 配置 文件 也 可 能 是 在 
另外 的 位 置 。 





$ git config -e --system 





Git 的 三 个 配置 文件 分 别 是 版 本 库 级 别 的 配置 文件 、 全 局 配置 文件 


《用 户主 目录 下 ) 和 系统 级 配置 文件 /etc 目录 下 ) 。 其 中 版 本 库 级 别 
的 配置 文件 的 优先 级 最 高 ， 全 局 配置 文件 次 之 ， 系 统 级 配置 文件 优先 级 
最 低 。 这 样 的 优先 级 设置 可 以 让 版 本 库 .git 目 录 下 的 config 文 件 中 的 配置 
窗 盖 用 户主 目录 下 的 Git 环 境 配 置 ， 而 用 户主 目录 下 的 配置 也 可 以 窗 冀 
系统 的 Git 配 置 文件 。 








执行 前 面 的 三 个 git config 命 令 后 会 看 到 这 三 个 级 别 的 配置 文件 的 格 
式 和 内 容 ， 原 来 Git 配 置 文件 采用 的 是 INI 文 件 格 式 。 示 例如 下 : 





$ cat /path/to/my/workspace/demo/ .git/config 
[core] 


repositoryformatversion = 0 
filemode = true 

bare = false 
logallrefupdates = true 


git config 命 令 可 以 用 于 读 取 和 更 改 INI 配 置 文件 的 内 容 。 使 用 只 带 
一 个 参数 的 git config<section>.<key> 命 令 可 用 来 读 取 INI 配 置 文件 中 某 个 
配置 的 键 值 ， 例 如 读 取 [core] 小 节 的 bare 的 属性 值 ， 可 以 用 如 下 命令 : 


$ git config core.bare 
false 


如 果 想 更 改 或 设置 INI 文 件 中 茶 个 属性 的 值 也 非常 简单 ， 命 令 格式 
是 : git config<section>.<key><value>。 可 以 用 如 下 操作 : 


$ git config a.b something 
$ git config x.y.z others 


如 果 打 开 .git/config 文 件 ， 会 看 到 如 下 内 容 : 





[La] 

b = something 
[x "y"] 

z = others 





对 于 类 似 于 [x"y"] 这 样 的 配置 小 节 会 在 本 书 第 三 篇 介绍 远程 版 本 库 
的 革 节 中 经 第 过 到 。 


从 上 面 的 介绍 中 可 以 看 到 ， 使 用 git config 命 令 可 以 非常 方便 地 操作 
INI 文 件 ， 实 际 上 可 以 用 git config 命 令 操 作 任何 其 他 的 INI 文 件 。 


' 向 配置 文件 test.ini 中 添加 配置 。 





$ GIT_CONFIG=test,.ini git config a.b.c.d "hello, world" 





. 从 配置 文件 test.ini 中 读 取 配 置 。 





$ GIT_CONFIG=test, ini git config a.b.c.d 
hello, world 





后 面 介 绍 的 gittsvn 和 Gistore 等 软件 就 是 使 用 该 技术 读 写 各 目 专 有 的 
配置 文件 的 。 








4.4 思考 : 是 谁 完成 的 提交 





在 本 章 的 一 开始 先 为 Git 设 置 了 全 局 配置 变量 user.name 和 
user.email， 如 果 不 设 置 会 有 什么 结果 呢 ? 


执行 下 面 的 命令 ， 删 除 Git 全 局 配置 文件 中 关于 user.name 和 


user.email 的 设置 : 





$ git config --unset --global user.name 
$ git config --unset --global user.email 





这 样 一 来 ， 关 于 用 户 姓名 和 邮件 的 设置 都 被 清空 了， 执行 下 面 的 命 
令 将 看 不 到 输出 。 





$ git config user.name 
$ git config user.email 





下 面 再 尝试 一 次 提交 ， 看 看 提交 的 过 程 会 有 什么 不 同 ， 以 及 提交 之 


后 显示 的 提交 者 是 谁 ? 


在 下 面 的 命令 中 使 用 了 --allow-empty 人 参数 ， 这 是 因为 如 果 没 有 对 工 
作 区 的 文件 进行 任何 修改 ，Git 默 认 不 会 执行 提交 ， 使 用 --allow-empty 参 
数 后 允许 执行 空白 提交 ， 操 作 如 下 : 





$ cd /path/to/my/workspace/demo 
$ git commit --allow-empty -m "who does commit?" 


[master 252dc53] who does commit? 

Committer: JiangXin <jiangxin@hp.moon.ossxp.com> 

Your name and email address were configured automatically based 

on your username and hostname. Please check that they are accurate. 

You can suppress this message by setting them explicitly: 
git config --global user.name "Your Name" 
git config --global user.email you@example.com 

If the identity used for this commit is wrong, you can fix it with: 
git commit --amend --author='Your Name <you@example.com>" 








喔 ， 因 为 没有 设置 配置 变量 username 和 user.email， 提 交 后 输出 乱 
得 一 塌 糊 涂 。 仔 细 看 看 上 面 的 执行 git commit 命 令 后 的 输出 ， 原 来 Git 提 
供 了 详细 的 帮助 来 告诉 我 们 如 何 设置 必需 的 配置 变量 ， 以 及 如 何 修改 之 
前 提交 中 出 现 的 错误 的 提交 者 信息 。 











如 果 此 时 查看 版 本 库 的 提交 日 志 ， 会 看 到 有 两 次 提交 。 


注意 ， 下 面 的 输出 与 你 动手 实践 时 得 到 的 输出 肯定 有 所 不 同 ， 一 方 
面 因为 提交 时 间 会 不 一 样 ， 另 外 一 方面 因为 由 40 位 十 六 进 制 数字 组 成 的 
提交 ID 也 不 可 能 一 样 。 甚 至 ， 本 书 中 几 是 您 杀 目 完成 的 提交 ， 相 关 的 40 
位 魔幻 般 的 数字 ID 也 都 会 不 一 样 (原因 会 在 后 面 的 章节 中 看 到 〉 。 因 
此 ， 几 是 涉及 数字 ID 和 本 书 中 的 示例 不 一 致 的 时 候 ， 以 你 目 己 的 数字 ID 
为 准 ， 本 书 提供 的 示例 仅 供 参考 ， 切 记 。 








$ git 1og --pretty=fuller 
commit 252dc539b5b5f9683edd54849c8e0a246e88979c 


Author: JiangXin <jiangxin@hp.moon.ossxp.com> 
AuthorDate: Mon Nov 29 10:39:35 2010 +0800 
Commit: JiangXin <jiangxin@hp.moon.ossxp.com> 


CommitDate: Mon Nov 29 10:39:35 2010 +0800 
who does commit? 
commit 9e8a761ff9dd343a1380032884f488a2422c495a 


Author: Jiang Xin <jiangxin@ossxp.com> 
AuthorDate: Sun Nov 28 12:48:26 2010 +0800 
Commit: Jiang Xin <jiangxin@ossxp.com> 


CommitDate: Sun Nov 28 12:48:26 2010 +0800 
initialized. 





最 早 的 提交 《提交 ID 为 9e8a761...) ， 提 交 者 的 信息 是 由 之 前 设置 
的 配置 变量 user.name 和 user.email 给 出 的 。 而 最 新 的 提交 (提交 ID 为 
252dc53...) 因为 删除 了 username 和 user.email， 提 交 时 Git 对 提交 者 的 用 
户 名 和 邮件 地 址 进行 了 大 胆 的 猜测 ， 这 个 猜测 可 能 是 错 的 。 





为 了 保证 提交 时 提交 者 和 作者 信息 的 正确 性 ， 需 要 重新 恢复 
user.name 和 user.email 的 设置 。 记 住 ， 不 要 照抄 照搬 下 面 的 命令 ， 请 使 


用 您 自己 的 用 户 名 和 邮件 地 址 。 





$ git config --global user.name "Jiang Xin" 
$ git config --global user.email jiangxin@ossxp.com 





然后 执行 下 面 的 命令 ， 重 新 修改 最 新 的 提交 ， 改 正 作 者 和 提交 者 的 


错误 信息 。 





$ git commit --amend --allow-empty --reset-author 





说 明 : 


. 参数 --amend 是 对 刚刚 的 提交 进行 修补 ， 这 样 就 可 以 改正 前 面 的 
提交 中 错误 的 用 户 名 和 邮件 地 址 ， 而 不 会 产生 另外 的 新 提交 。 


. 参数 --allow-empty 使 得 空白 提交 被 允许 。 之 所 以 这 里 必须 使 用 此 


参数 是 因为 要 进行 的 修补 提交 实际 上 是 一 个 空白 提交 。 


. 参数 --reset-authot 的 含义 是 将 Author (作者 ) 的 ID 同步 修改 ， 和 否 
则 只 会 影响 提交 者 (Commit) 的 ID。 使 用 此 参数 也 会 重 置 AuthorDate 信 


~ 


AN O 


通过 日 志 可 以 看 到 ， 最 新 提交 的 作者 和 提交 者 的 信息 已 经 改正 了 。 





$ git 1og --pretty=fuller 
commit aoc641e92b10d8bccaled1bf84ca80340fdefee6 


Author : Jiang Xin <jiangxin@ossxp.com> 
AuthorDate: Mon Nov 29 11:00:06 2010 +0800 
Commit: Jiang Xin <jiangxin@ossxp.com> 


CommitDate: Mon Nov 29 11:00:06 2010 +0800 
who does commit? 
commit 9e8a761ff9dd343a1380032884f488a2422c495a 
Author: Jiang Xin <jiangxin@ossxp.com> 
AuthorDate: Sun Nov 28 12:48:26 2010 +0800 
Commit: Jiang Xin <jiangxin@ossxp.com> 
CommitDate: Sun Nov 28 12:48:26 2010 +0800 
initialized. 


| 











4.5 思考 :; 随意 设置 提交 者 姓名 ， 是 个 太 不 安全 


使 用 过 CVS 和 Subversion 等 集中 式 版 本 控制 系统 的 用 户 都 知道 ， 每 
次 提交 的 时 候 需 要 认证 ， 认 证 成 功 后 ， 登 录 ID 束 作为 提交 者 有 D 出 现在 版 
本 库 的 提交 日 志 中 。 很 显然 ， 对 于 CVS 和 Subversion 这 样 的 版 本 控制 系 
统 而 言 ， 很 难 冒 充 他 人 提交 。 像 Git 这 样 的 分 布 式 版 本 控制 系统 ， 可 以 
随心 所 欲 地 设 定 提交 者 ， 这 似乎 太 不 安全 了 。 








Git 可 以 随意 设置 提交 的 用 户 名 和 邮件 地 址 信息 ， 这 是 分 布 式 版 本 
控制 系统 的 特性 使 然 ， 每 个 人 部 是 自己 版 本 库 的 主人 ， 很 难 也 没有 必要 
进行 号 份 认证 ， 因 而 也 就 无 法 使 用 经 过 认证 的 用 户 名 作为 提交 的 用 户 
名 。 


在 进行 “ 独 妥 ”的 时 候 ， 还 要 强制 为 目 己 加 上 一 个 “指纹 识别 ”， 实 在 
是 太 没 有 必要 了 ， 但 是 团队 合作 时 授权 就 成 为 必需 了 。 通 常 ， 团 队 协 作 
时 会 设置 一 个 共享 版 本 库 ， 在 团队 成 员 癌 共享 版 本 库 传送 推送) 新 提 
交 时 ， 会 进行 用 户 身 份 认证 并 检查 授权 。 一 旦 用 户 通过 身份 认证 ， 一 般 
来 说 不 会 对 提交 中 的 包含 的 提交 者 ID 做 进一步 检查 ， 但 Android 项 目 是 
个 例外 。 








Android 项 目 为 了 更 好 地 使 用 Git 实 现 对 代码 的 集中 管理 ， 开 发 了 一 
套 叫 作 Gerrit 的 审核 服务 器 来 管理 Git 提 交 ， 对 提交 者 的 邮件 地 址 进行 审 


核 。 例 如 下 面 的 示例 中 ， 在 向 Gerrit 服 务 器 推送 的 时 候 ， 提 交 中 的 提交 

者 邮件 地 址 为 jiangxin@ossxp.com， 但 是 在 Gerrit 中 注册 用 户 时 使 用 的 邮 
件 地 址 为 jiangxin@moon.ossxp.com。 因 为 两 者 不 匹配 ， 从 而 导致 推送 失 
败 。 








$ git push origin master 
Counting objects: 3, done. 
Writing objects: 100% (3/3), 222 bytes, done. 
Total 3 (delta 0), reused 0 (delta 0) 
To ssh://localhost:29418/new/project.git 
! [remote rejected] master -> master (you are not committer jiangxin@ossxp.com) 
error: failed to push Some refs to 'ssh://localhost:29418/new/project.git' 








即使 没有 使 用 类 似 Gerrit 的 服务 ， 作 为 提交 者 也 不 应 该 随意 改变 配 
置 变量 user.name 和 user.email 的 设置 ， 因 为 当 多 人 协同 时 这 样 做 会 给 他 
人 造成 迷惑 ， 也 会 给 一 些 项 目 管理 软件 造成 及 烦 。 


例如 ，Redmine 是 一 款 实现 需求 管理 和 缺陷 跟踪 的 项 目 管理 软件 ， 
可 以 与 Git 版 本 库 实 现 整合 。Git 的 提交 可 以 直接 关闭 Redmine 上 的 Bug， 
同时 Git 的 提交 还 可 以 反映 出 项 目 成 员 的 工作 进度 。Redmine 中 的 用 户 
(项 目 成 员 ) 用 一 个 ID 作 标 识 ， 而 Git 的 提交 者 则 用 一 个 包含 用 户 名 和 
邮件 地 址 的 字符 串 ， 如 何 将 Redmine 的 用 户 和 Git 的 提交 者 相关 联 呢 ? 
Redmine 提 供 了 一 个 配置 界面 用 于 设置 二 者 之 间 的 映射 ， 如 图 4-1 所 示 。 
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图 4-1 Redmine 中 用 户 ID 和 Git 提 交 者 关联 


显然 ， 如 果 在 Git 提 交 时 随意 变更 提交 者 的 姓名 和 邮件 地 址 ， 就 会 
破坏 Redmine 软 件 中 设置 好 的 用 户 对 应 关系 。 


4.6 思考 : 命令 别名 是 干什么 的 


在 本 章 的 一 开始 ， 我 们 通过 对 alias.ci 等 Git 配 置 变量 的 设置 为 Git 设 
置 了 命令 别名 。 命 令 别 名 可 以 帮助 用 户 解决 从 其 他 版 本 控制 系统 迁移 到 
Git 后 的 使 用 习惯 问题 。CVS 和 Subversion 等 在 提交 的 时 候 ， 一 般 习 惯 使 
用 ci (check ip) 子 命令 ， 在 检 出 的 时 候 则 习惯 使 用 co 〈check out) 子 命 
令 。 如 果 Git 不 能 提供 对 ci 和 co 这 类 简洁 命令 的 支持 ， 对 于 拥有 其 他 版 本 
控制 系统 使 用 经 验 的 用 户 来 说 ，Git 的 用 户 体检 就 会 打折 扣 。 幸 好 聪明 
的 Git 提 供 了 别名 机 制 ， 可 以 满足 用 户 特 殊 的 使 用 习惯 。 


本 章 前 面 列 出 的 四 条 别名 设置 指令 ， 创 建 的 是 最 常用 的 几 个 Git 别 
名 。 实 际 上 别名 还 可 以 包含 命令 参数 ， 例 如 下 面 的 别名 设置 指令 : 








$ git config --global alias.ci "commit -s" 





如 上 设置 后 ， 当 使 用 git ci 命令 提交 时 ， 会 自动 带 上 -ss 参数， 这 样 会 
在 提交 说 明 中 自动 添加 上 包含 提交 者 姓名 和 邮件 地 址 的 签名 标识 ， 类 似 
于 Signed-off-by:User Name<email@address>。 这 对 于 一 些 项 目 (Git、 


Linux kernel、Android 等 ) 来 说 是 必要 甚至 是 必需 的 。 





不 过 ， 本 书 会 尽量 避免 使 用 别名 命令 ， 以 免 由 于 您 因为 尚未 设置 别 
名 而 造成 困扰 。 


4.7 备份 本 章 有 的 工作 成 果 


执行 下 面 的 命令 ， 算 是 对 本 章 工作 成 果 的 备份 : 





$ cd /path/to/my/workspace 

$ git clone demo demo-step-1 
Cloning into demo-step-1... 
done. 





第 5 章 ”Git 暂 存 区 





上 一 章 主 要 学 习 了 二 个 命令 : git init、git add 和 git commit， 这 三 个 
命令 可 以 说 是 版 本 库 创建 的 三 部 曲 。 同 时 还 通过 对 几 个 问题 的 思考 了 解 
了 Git 版 本 库 在 工作 区 中 的 布局 ，Git 三 个 等 级 的 配置 文件 及 Git 的 别名 命 


令 等 内 容 。 





在 上 一 章 的 实践 中 ，DEMO 版 本 库 经 历 了 两 次 提交 ， 可 以 用 gitlog 
查看 提交 日 志 〈 附 加 的 --stat 参 数 可 以 看 到 每 次 提交 的 文件 变更 统计 〉。 








$ cd /path/to/my/workspace/demo 
$ git 10g --stat 
commit ao0c641e92b10d8bccaled1bf84ca80340fdefee6 
Author: Jiang Xin <jiangxin@ossxp.com> 
Date: Mon Nov 29 11:00:06 2010 +0800 
who does commit? 
commit 9e8a761ff9dd343a1380032884f488a2422c495a 
Author: Jiang Xin <jiangxin@ossxp.com> 
Date: Sun Nov 28 12:48:26 2010 +0800 
initialized. 
welcome.txt | 1 + 
1 files changed, 1 insertions(+), 0 deletions(-) 











可 以 看 到 第 一 次 (最 早 的 ) 提交 对 文件 welcome.txt 有 一 行 变更 ， 而 
第 二 次 (最 新 的 ) 提交 因为 是 使 用 --allow-empty 参 数 进行 的 一 次 空 所 
交 ， 所 以 提交 说 明 中 看 不 到 任何 对 实质 内 容 的 修改 。 


下 面 我 们 将 仍 在 这 个 工作 区 继续 新 的 实践 和 学 习 ， 以 掌握 Git 的 一 
个 最 重要 概念 : 暂 存 区 。 


5.1 ”修改 不 能 卫 接 提交 吗 


首先 更 改 welcome.txt 文 件 ， 在 这 个 文件 后 面 妃 加 一 行 。 可 以 使 用 下 
面 的 命令 实现 内 容 的 追加 : 





$ echo "Nice to meet you." >> welcome.txt 








这 时 可 以 通过 执行 git diff 命 令 看 到 修改 后 的 文件 与 版 本 库 中 的 文件 
的 差异 。【〔 实 际 上 这 人 句 话 有 问题 ， 与 本 地 比较 的 不 是 版 本 库 中 的 文件 ， 
而 是 一 个 中 间 状 态 的 文件 。) 








$ git diff 
diff --git a/welcome.txt b/welcome.txt 
index 18832d3. .fd3c069 100644 
- a/welcome.txt 
+++ b/welcome,.txt 
@@ -1 +1, 2 @@ 
Hello. 
+Nice to meet you， 





对 差异 输出 是 不 是 很 熟悉 ?在 之 前 介绍 版 本 库 的 “黑暗 的 史前 时 
代 ” 时 ， 甸 经 展示 了 diff 命 令 的 输出 ， 两 者 的 格式 是 一 样 的 。 


既然 文件 修改 了 ， 那 么 残 提交 吧 。 提 交 能 够 成 功 吗 ? 





$ git commit -m "Append a nice line." 

# On branch master 

# Changes not staged for commit: 

(use "git add <file>..." to update what will be committed) 

(use "git checkout -- <file>,..." to discard changes in working directory) 


亲 半 亲 亲 


modified: welcome.txt 


## 
no _ changes added to commit (use "git add" and/or "git commit -a") 





提交 成 功 了 吗 ? 好 像 没有 ! 
提交 没有 成 功 的 证 据 : 


(1) 先 来 看 看 提交 日 志 ， 如 果 提 交 成 功 ， 应 该 有 新 的 提交 记录 出 
现 。 


下 面 使 用 了 精简 输出 来 显示 日 志 ， 以 便 更 简洁 和 清晰 地 看 到 提交 的 
历史 。 从 其 中 能 够 看 出 版 本 库 中 只 有 两 个 提交 ， 都 是 在 上 一 章 的 实践 中 
完成 的 。 也 就 是 次， 刚才 针对 修改 文件 的 提交 没有 成 功 ! 





$ git 1og --pretty=oneline 
a0c641e92b10d8bcca1led1bf84ca80340fdefee6 who does commit? 
9e8a761ff9dd343a1380032884f488a2422c495a initialized. 








(2) 执行 git diff 可 以 看 到 与 之 前 相同 的 差异 输出 ， 这 也 说 明了 之 
前 的 提交 没有 成 功 。 





(3) 执行 git status 碍 看 文件 状态 ， 可 以 看 到 文件 处 于 修改 状态 ， 而 
且 git status 命 令 的 输出 和 git commit 提 交 失 败 的 输出 信息 完全 一 样 ! 


(4) 对 于 习惯 了 像 CVS 和 Subversion 那 样 精简 的 状态 输出 的 用 户 ， 
可 以 在 执行 git status 时 附加 上 -s 参 数 ， 显 示 精 简 格 式 的 状态 输出 。 





$ git Status -S 
M welcome.txt 





提交 为 什么 会 失败 呢 ? 再 回 过 头 来 仔细 看 看 刚才 git commit 命 令 提 
交 失 败 后 的 输出 : 





# On branch master 

# Changes not staged for commit: 

(use "git add <file>..." to update what will be committed) 

(use "git checkout -- <file>,..." to discard changes in working directory ) 


# 
# 
## 
# modified: welcome.txt 
# 
n 


0 _ changes added to commit (use "git add" and/or "git commit -a") 





把 它 翻 译 成 中 文 则 是 : 













































































# 位 于 您 当前 工作 的 分 支 master 上 

# 下 列 修改 还 没有 加 入 到 提交 任务 〈 提 交 暂 存 区 ，stage) 中 ， 不 会 被 提交 : 

# (使 用 "git add <file>..." 命令 后 ， 改 动 就 会 加 入 到 提交 任务 中 ， 

# 要 在 下 一 次 提交 操作 时 才 被 提交 ) 

# (使 用 "git checkout -- <file>..." 命令 工作 区 中 当前 您 不 打算 
# 提交 的 修改 会 被 彻底 清除 ! ! ! ) 

## 

# 已 修改 : welcome ,txt 

## 

警告 ,提交 任务 是 空 的 只 ， 您 不 要 再 择 扰 我 啦 (除非 使 



































也 就 是 说 ， 需 要 对 修改 的 welcome.txt 文 件 执行 git add 命 令 ， 将 修改 
的 文件 添加 到 “提交 任务 ”中 ， 然 后 才能 提交 ! 








这 个 行为 真 的 很 奇怪 ， 对 于 其 他 版 本 控制 系统 来 说 执行 add 操 作 古 
回 版 本 库 中 添加 新 文件 用 的 ， 修 改 的 文件 (已 被 版 本 控制 跟 踩 的 文件 ) 
在 下 次 提交 时 会 直接 被 提交 。Git 的 这 个 古怪 的 行为 会 在 下 面 的 介绍 中 
得 到 解释 ， 大 家 会 逐渐 习惯 并 喜欢 Git 的 这 个 设计 。 





好 了 ， 现 在 就 将 修改 的 文件 < 添加 "到 提交 任务 中 吧 : 





$ git add welcome.txt 





现在 再 执行 一 些 Git 命 令 ， 看 看 当 执 行 完 “添加 ”操作 后 ，Git 库 友 生 
了 人 秆 竣 变 化 : 


` 执行 git diff 没 有 输出 ， 难 道 是 被 提交 了 ? 可 是 只 是 执行 了 “ 添 


加 ”到 提交 任务 的 操作 ， 相 当 于 一 个 “登记 ”的 命令 ， 并 没有 执行 提交 
哇 ? 





$ git diff 





. 这 时 如 果 与 HEAD (当前 版 本 库 的 头 指 针 ) 或 mastef 分 支 〈 当 前 
工作 分 支 ) 进行 比较 ， 就 会 发 现 有 差异 。 这 个 差异 才 是 正常 的 ， 因 为 尚 
未 真正 提交 嘛 。 





$ git diff HEAD 
diff --git a/welcome.txt b/welcome.txt 
index 18832d3..fd3c069 100644 
- a/welcome.txt 
+++ b/welcome.txt 
@@ -1 +1, 2 @@ 
Hello. 
+Nice to meet you， 





执行 git status 命 令 ， 状 态 输出 和 之 前 的 不 一 样 了 。 





$ git status 
# On branch master 
# Changes to be committed: 


(use "git reset HEAD <file>..." to unstage) 


modified: welcome.txt 





. 再 对 新 的 Git 状 态 输出 进行 翻译 : 





$ git status 

# 位 于 分 支 master 上 

Ws 

(如 果 你 后 悔 了 ， 可 以 使 用 "git reset HEAD <file>..." 命令 

将 下 列 改 动 撤 出 提交 任务 提交 和 暂 存 区 ， stage) ， 否 则 执行 提交 命令 
可 真 的 要 提交 号 ) 



























































已 修改 : welcome. txt 





亲 亲 和亲 亲 和 半 宁 





不 得 不 说 ，Git 太 人 性 化 了 ， 它 把 各 种 情况 下 可 能 使 用 到 的 命令 都 
告诉 给 用 户 了 ， 虽 然 这 显得 有 反 哆 呆 。 如 果 不 要 这 么 哆 哄 ， 可 以 像 下 面 
这 样 用 简洁 的 方式 显示 状态 : 





$ git status -s 
M welcome.txt 





上 面 的 精简 状态 输出 与 执行 git add 之 前 的 精简 状态 输出 相 比 ， 有 细 
微 的 差别 ， 友 现 了 吗 ? 


` 虽然 都 是 M (Modified) 标识 ,但 是 位 置 不 一 样 。 在 执行 git add 命 
令 之 前 ， 这 个 M 位 于 第 二 列 (第 一 列 是 一 个 空格 ) ， 在 执行 完 git add 之 


后 ， 字 符 M 位 于 第 一 列 (第 二 列 是 空白 ) 。 


. 位 于 第 一 列 的 字符 M 的 含义 是 : 版 本 库 中 的 文件 与 处 于 中 间 状 态 


一 一 提交 任务 (提交 和 暂 存 区 ，stage) 中 的 文件 相 比 有 改动 。 


. 位 于 第 二 列 的 字符 M 的 含义 是 : 工作 区 当前 的 文件 与 处 于 中 间 状 
态 一 一 提交 任务 (提交 暂 存 区 ，stage) 中 的 文件 相 比 有 改动 。 


是 不 是 还 有 一 些 不 明白 ? 为 什么 Git 的 状态 输出 中 提示 了 那么 多 让 
人 不 解 的 命令 ?为 什么 存在 一 个 提交 任务 的 概念 而 又 总 是 把 它 叫 作 暂 存 
区 (stage) ? 不 要 紧 ， 马 上 束 会 专题 讲述 “ 暂 存 区 ”的 概念 。 当 了 解 了 
Git 版 本 库 的 设计 原理 之 后 ， 理 解 相关 Git 命 令 束 易如反掌 了 。 


这 时 如 果 直 接 提交 (git commit) ， 加 入 提交 任务 的 welcome.txt 文 
件 的 更 改 束 会 被 提交 入 库 了 。 但 是 先 不 忙 着 执行 提交 ， 再 执行 一 些 操 
作 ， 看 看 是 否 会 被 彻底 地 搞 糊 涂 。 


(1) 继续 修改 一 下 welcome.txt 文 件 〈 在 文件 后 面 再 追加 一 行 ) 。 





$ echo "Bye-Bye." >> welcome.txt 





(2) 然后 执行 git status， 查 看 一 下 状态 : 





$ git status 

# On branch master 

# Changes to be committed: 

(use "git reset HEAD <file>..." to unstage) 


modified: welcome.txt 


Changes not staged for commit: 


(use "git add <file>..." to update what will be committed) 
(use "git checkout -- <file>,..." to discard changes in working directory) 
modified: welcome.txt 


亲 半 闪闪 半 半 亲 亲 和 半 宁 





状态 输出 居然 是 之 前 出 现 的 两 种 不 同 状态 输出 的 杂 合 体 。 


(3) 如 果 显 示 精 简 的 状态 输出 ， 也 会 看 到 前 面 两 种 精简 输出 的 杂 
合体 。 


$ git Status -S 
MM welcome.txt 


上 面 的 更 为 复杂 的 Git 状 态 输出 可 以 这 么 理解 :不 但 版 本 库 中 最 新 
提交 的 文件 与 处 于 中 间 状 态 一 一 提交 任务 提交 和 暂 存 区 ，stage〉 中 的 文 
件 相 比 有 改动 ， 而 且 工作 区 当前 的 文件 与 处 于 中 间 状 态 一 一 提交 任务 
提交 暂 存 区 ，stage) 中 的 文件 相 比 也 有 改动 。 














即 现在 welcome.txt 有 三 个 不 同 的 版 本 ， 一 个 在 工作 区 ， 一 个 在 等 待 
提交 的 暂 存 区 ， 还 有 一 个 是 版 本 库 中 最 新 版 本 的 welcome.txt。 通 过 不 同 
的 参数 调用 git diff 命 令 可 以 看 到 不 同 状态 下 welcome.txt 文 件 的 差异 。 








(1) 不 带 任何 选项 和 参数 调用 git diff 显 示 工 作 区 的 最 新 改动 ， 即 
工作 区 与 提交 任务 (提交 暂 存 区 ，stage〉 中 相 比 的 差异 。 


$ git diff 
diff --git a/welcome.txt b/welcome.txt 
index fd3c069, .51dbfd2 100644 
-- a/welcome.txt 
+++ b/welcome.txt 
QQ -1, 2 +1, 3 @@ 
Hello. 
Nice to meet you. 
+Bye-Bye. 


二 一 


(2) 将 工作 区 和 HEAD《 当 前 工作 分 文 ) 相 比 ， 会 看 到 更 多 的 产 





$ git diff HEAD 
diff --git a/welcome.txt b/welcome.txt 
index 18832d3..51dbfd2 100644 
--- a/welcome.txt 
+++ b/welcome.txt 
@@ -1 +1, 3 @@ 
Hello. 
+Nice to meet you， 
+Bye-Bye. 





(3) 通过 参数 --cached 或 --staged 调 用 git diff 命 令 ， 看 到 的 是 提交 和 暂 
存 区 《提交 任务 ，stage) 和 版 本 库 中 文件 的 差异 。 





$ git diff --cached 
diff --git a/welcome.txt b/welcome.txt 
index 18832d3..fd3c069 100644 
--- a/welcome.txt 
+++ b/welcome.txt 
@@ -1 +1, 2 @@ 
Hello. 
+Nice to meet you， 








好 了 ， 现 在 是 时 候 提 交 了 。 执 行 git commit 命 令 进行 提交 : 





$ git commit -m "which version checked in?" 
[master e695606] which version checked in? 
1 files changed, 1 insertions(+), 0 deletions(-) 





这 次 提交 终于 成 功 了 。 如 何 证 明 提 交 成 功 了 呢 ? 





(1) 通过 但 看 提交 日 志 ， 看 到 了 新 的 提交 : 





$ git 1og --pretty=oneline 
e695606fc5e31b2ff9038a48a3d363f4c21a3d86 which version checked in? 


ao0c641e92b10d8bcca1led1bf84ca80340fdefee6 who does commit? 
9e8a761ff9dd343a1380032884f488a2422c495a Initialized ， 





(2) 查看 精简 的 状态 输出 。 


状态 输出 中 ， 文 件 名 的 前 面 少 了 一 个 字母 MY， 即 只 剩 下 第 二 列 的 字 
母 M。 那 么 第 一 列 的 M 哪 里 去 了 ? 被 提交 了 呐 。 即 提交 任务 “提交 暂 存 
区 ，stage) 中 的 内 容 被 提交 到 版 本 库 中 。 所 以 ， 第 一 列 会 因为 提交 暂 存 
区 《提交 任务 ，stage) 与 版 本 库 中 的 状态 一 致 而 显示 一 个 空 日。 





$ git status -s 
M welcome.txt 





提交 的 welcome.txt 是 哪个 版 本 呢 ? 可 以 通过 执行 git diff 或 git diff 
HEAD 命 令 查看 差异 。 虽 然 命 令 git diff 和 git diff HEAD 的 比较 过 程 并 不 
相同 (可 以 通过 strace 命 令 跟 躁 命令 执行 过 程 中 的 文件 访问 ) ， 但 是 会 
看 到 如 下 面 所 示 的 相同 的 差异 输出 结果 。 





$ git diff 
diff --git a/welcome.txt b/welcome.txt 
index fd3c069, .51dbfd2 100644 
-- a/welcome.txt 
+++ b/welcome.txt 
QQ -1, 2 +1, 3 @@ 
Hello. 
Nice to meet you. 
+Bye-Bye. 


mr 一， 


5.2 ”理解 Git 和 暂 存 区 (stage) 


将 上 面 的 实践 从 头 至 尾 操 作 一 裔 ， 不 知道 您 的 感想 如 何 : 
. 一 “被 有限 花 结 乱 的 Git 魔 法 彻底 搞 糊 涂 了 ? ” 


` 一 “Git 为 什么 这 么 折磨 人 ， 修 改 的 文件 直接 提交 不 就 完了 
吗 ? 洲 


. 一 “看 不 出 Git 这 么 做 有 什么 好 和 处? ” 








上 面 的 实践 过 程 有 意 无 意 地 透漏 了 “和 暂 存 区 ”的 概念 。 为 了 避免 用 户 
被 新 概念 吓 坏 ， 在 暂 存 区 出 现 的 地 方 又 同时 使 用 了 “提交 任务 ”这 一 更 易 
理解 的 概念 ， 但 是 暂 存 区 〈 称 为 stage 或 index) 才 是 其 真正 的 名 称 。 我 
认为 Git 暂 存 区 的 设计 是 Git 最 成 功 的 设计 之 一 ， 但 也 是 最 难 理解 的 。 











在 版 本 库 .git 目 录 下 有 一 个 index 文 件 ， 下 面 针 对 这 个 文件 做 一 个 有 
趣 的 试验 。 要 说 明 的 是 : 这 个 试验 是 用 1.7.3 版 本 的 Git 进 行 的 ， 低 版 本 
的 Git 因 为 没有 针对 git status 命 令 进行 优化 设计 ， 需 要 运行 git diff 命 令 才 


能 看 到 index 文 件 的 日 期 蕉 变化 ， 其 体操 作 步 又 如 下 。 








(1) 首先 执行 git checkout 命 令 ( 后 面 会 介绍 此 命令 ) ， 撤 销 工作 
区 中 welcome.txt 文 件 尚 未 提交 的 修改 。 





$ git checkout -- welcome ,txt 
$ git status -s # 执行 git diff ， 如 果 git 版 本 号 小 于 1.7.3 








(2) 通过 状态 输出 可 以 看 到 工作 区 已 经 没有 改动 了 。 查 看 一 
下 .giUindex 文 件 ， 注 意 该 文件 的 时 间 惟 为 : 19:37:44。 





$ 1s --full-time .git/index 
-rw-r--r-- 1 jiangxin jiangxin 112 2010-11-29 19:37:44.625246224 +0800 .git/index 





(3) 再 次 执行 git status 命 令 ， 然 后 显示 .giyindex 文 件 的 时 间 惟 为 : 
19:37:44， 与 上 面 的 一 样 。 








$ git status -s # 执行 git diff ， 如 果 git 版 本 号 小 于 1.7.3 
$ 1s --full-time .git/index 
-rw-r--r-- 1 jiangxin jiangxin 112 2010-11-29 19:37:44.625246224 +0800 .git/index 





(4) 现在 更 改 一 下 welcome.txt 的 时 间 戳 ， 但 是 不 改变 它 的 内 容 。 
然后 再 执行 git status 命 令 ， 碍 看 .giVindex 文 件 的 时 间 惟 为 : 19:42:06。 





$ touch welcome.txt 

$ git status -s # 执行 git diff ， 如 果 git 版 本 号 小 于 1.7.3 

$ 1s --full-time .git/index 

-rw-r--r-- 1 jiangxin jiangxin 112 2010-11-29 19:42:06.980243216 +0800 .git/index 








看 到 了 吗 ， 时 间 惟 改变 了 ! 


这 个 试验 说 明 当 执行 git status 命 令 〈 或 者 git diff 命 令 ) 扫描 工作 区 
改动 的 时 候 ， 先 依据 .git/index 文 件 中 记录 的 (用 于 跟踪 工作 区 文件 的 ) 
时 间 戳 、 长 度 等 信息 判断 工作 区 文件 是 否 改变 ， 如 果 工 作 区 文件 的 时 间 





玲 改 变 了 ， 说 明文 件 的 内 容 可 能 被 改变 了 ， 需 要 打开 文件 ， 读 取 文 件 内 
容 ， 与 更 改 前 的 原始 文件 相 比 较 ， 判 断 文 件 内 容 是 否 被 更 改 。 如 果 文 件 
内 容 没 有 改变 ， 则 将 该 文件 新 的 时 间 惟 记 录 到 .giVindex 文 件 中 。 因 为 如 
果 要 判断 文件 是 售 更 改 ， 使 用 时 间 戳 、 文 件 长 度 等 信息 进行 比较 要 比 通 
过 文件 内 容 比较 要 快 得 多 ， 所 以 Git 这 样 的 实现 方式 可 以 让 工作 区 状态 
扫描 更 快速 地 执行 ， 这 也 是 Git 高 效 的 原因 之 一 。 


文件 .giVindex 实 际 上 就 是 一 个 包含 文件 索引 的 目录 树 ， 像 是 一 个 虚 
拟 的 工作 区 。 在 这 个 虚拟 工作 区 的 目录 树 中 ， 记 录 了 文件 名 和 文件 的 状 
态 信息 〈 时 间 戳 和 文件 长 度 等 ) 。 文 件 的 内 容 并 没有 存储 在 其 中 ， 而 是 








保存 在 Git 对 象 库 .gityobjects 目 录 中 ， 文 件 索 引 建立 了 文件 和 对 象 库 中 对 
象 实体 之 间 的 对 应 。 图 5-1 展 示 了 工作 区 、 版 本 库 中 的 和 暂 存 区 和 版 本 库 
之 间 的 关系 。 





图 5-1 工作 区 、 版 本 库 、 暂 存 区 原理 图 


从 图 5-1 中 可 以 看 到 部 分 Git 命 令 是 如 何 影响 工作 区 和 和 暂 存 区 的 。 这 
命令 的 面纱 将 在 接 下 来 的 几 个 章节 中 彻底 揭 开 ， 下 面 就 对 这 些 命令 进 


行 简要 说 明 : 





` 图 中 左 侧 为 工作 区 ， 右 侧 为 版 本 库 。 在 版 本 库 中 标记 为 Index 的 区 
域 是 暂 存 区 ， 标 记 为 masterf 的 是 master 分 支 所 代表 的 目录 树 。 


~ 


` 图 中 可 以 看 出 ， 此 时 HEAD 实 际 是 指向 mastet 分 支 的 一 个 “ 游 
标 ”， 所 以 图 示 的 命令 中 出 现 HEAD 的 地 方 可 以 用 mastet 来 替换 。 


` 图 中 的 objects 标 识 的 区 域 为 Git 的 对 象 库 ， 实 际 位 于 .git/objects 目 
录 下 ， 这 一 点 会 在 后 面 的 章节 中 重点 介绍 。 


当 对 工作 区 修改 (或 新 增 ) 的 文件 执行 git add 命 令 时 ， 暂 存 区 的 
目录 树 将 被 更 新 ， 同 时 工作 区 修改 (或 新 增 ) 的 文件 内 容 会 被 写 入 到 对 
象 库 中 的 一 个 新 的 对 象 中 ， 而 该 对 象 的 ID 被 记录 在 暂 存 区 的 文件 索引 
中 。 


当 执行 提交 操作 (git commit) 时 ， 暂 存 区 的 目录 树 会 写 到 版 本 
库 (对 象 库 ) 中 ，master 分 支 会 做 相应 的 更 新 ， 即 master 最 新 指向 的 目录 
树 就 是 提交 时 原 暂 存 区 的 目录 树 。 


当 执 行 git reset HEAD 命 令 时 ， 暂 存 区 的 目录 树 会 被 重 写 ， 会 被 


mastet 分 支 指向 的 目录 树 所 替换 ， 但 是 工作 区 不 受 影响 。 


: 当 执行 git rm--cached 命 令 时 ， 会 直接 从 暂 存 区 删除 文件 ， 工 作 区 
则 不 做 出 改变 。 


. 当 执 行 git checkout. 或 git checkout-- 命 令 时 ， 会 用 暂 存 区 全 部 的 文 
件 或 指定 的 文件 替换 工作 区 的 文件 。 这 个 操作 很 危险 ， 会 清除 工作 区 中 
未 添加 到 暂 存 区 的 改动 。 


. 当 执 行 git checkout HEAD. 或 git checkout HEAD 命 令 时 ， 会 用 
HEAD 指 向 的 mastet 分 支 中 的 全 部 或 部 分 文件 替换 暂 存 区 和 工作 区 中 的 
文件 。 这 个 命令 也 是 极 具 危险 性 的 ， 因 为 不 但 会 清除 工作 区 中 未 提交 的 
改动 ， 也 会 清除 暂 存 区 中 未 提交 的 改动 。 


5.3 ”Git Diff 魔 法 





本 章 的 实践 展示 了 具有 魔法 效果 的 命令 : git diff。 在 不 同 参数 的 作 
用 下 ，git diff 的 输出 并 不 相同 。 在 理解 了 Git 中 的 工作 区 、 暂 存 区 和 版 本 
库 《〈 当 前 分 文 ) 的 最 新 版 本 分 别 是 三 个 不 同 的 目录 树 后 ， 就 非常 好 理解 
git diff 的 魔法 般 的 行为 了 。 











1. 工 作 区 、 暂 存 区 和 版 本 库 的 目录 树 浏 览 





有 什么 办 法 能 够 像 查 看 工作 区 一 样 直观 地 查看 暂 存 区 及 HEAD 中 的 
目录 树 吗 ? 





对 于 HEAD (版 本 库 中 当前 提交 〉 指 疝 的 目录 树 ， 可 以 使 用 Git 底 层 
命令 ls-tree 来 查看 。 





$ git ls-tree -1 HEAD 
100644 blob fd3c069c1de4f4bc9b15940f490aeb48852f3c42 25 welcome.txt 





其 中 : 


. 使 用 -1 参数 可 以 显示 文件 的 大 小 。 上 面 的 welcome.txt 的 大 小 为 25 字 


二 


. 输出 的 welcome.txt 文 件 条 目 从 左 至 右 ， 第 一 个 字段 是 文件 的 属性 


(rw-t--t--) ， 第 二 个 字段 说 明 是 Git 对 象 库 中 的 一 个 blob 对 象 ( 文 
件 ) ， 第 三 个 字段 则 是 该 文件 在 对 象 库 中 对 应 的 ID 一 一 一 个 40 位 的 
SHA1 哈 希 值 格式 的 ID (这 个 会 在 后 面 介 绍 ) ， 第 四 个 字段 是 文件 大 


小 ， 第 五 个 字段 是 文件 名 。 





在 浏览 暂 存 区 中 的 目录 树 之 前 ， 首 先 清除 工作 区 当前 的 改动 。 通 过 
git clean-fd 命 令 清除 当前 工作 区 中 没有 加 入 版 本 库 的 文件 和 目录 〔 非 跟 
踊 文 件 和 目录 ) ， 然 后 执行 git checkout. 命 令 ， 用 和 暂 存 区 内 容 刷 新 工作 
区 。 





$ cd /path/to/my/workspace/demo 
$ git clean -fd 
$ git checkout . 





然后 开始 在 工作 区 中 做 出 一 些 修 改修 改 welcome.txt， 再 增加 一 个 
子 目录 和 文件 ) ， 并 添加 到 暂 存 区 ， 最 后 再 对 工作 区 做 出 修改 。 





$ echo "Bye-Bye." >> welcome .txt 

$ mkdir -p a/b/c 

$ echo "Hello." > a/b/c/hello.txt 

$ git add . 

$ echo "Bye-Bye." >> a/b/c/hello.txt 
$ git status -s 

AM a/b/c/hello.txt 

M welcome.txt 








上 面 的 命令 运行 完毕 后 ， 通 过 精简 的 状态 输出 可 以 看 出 ， 工 作 区 、 
暂 存 区 和 版 本 库 当 前 分 广 的 最 新 版 本 “HEAD) 各 不 相同 。 先 来 看 看 工 
Ee se: 








$ find . -path ./.git -prune -0 -type f -printf "%-20p\t%s\n" 
./welcome.txt 34 
./a/b/c/hello.txt 16 





显示 暂 存 区 的 目录 树 ， 可 以 使 用 git ls-files 命 令 





$ git ls-files -s 
100644 18832d35117ef2f013c4009f5b2128dfaeff354f 0 a/b/c/hello.txt 
100644 51dbfd25a804c30e9d8dc441740452534de8264b 0 welcome.txt 





注意 ， 这 个 输出 与 之 前 使 用 git ls-tree 命 令 的 输出 不 一 样 ， 其 中 第 三 
个 字段 不 是 文件 大 小 而 是 暂 存 区 编写。 如 果 想 针对 和 暂 存 区 的 目录 树 使 用 
git ls-tree 人 命令， 需要 先 将 暂 存 区 的 目录 树 写 入 Git 对 象 库 〈 用 git write- 
tree 命 令 ) ， 然 后 针对 该 目录 树 执行 git ls-tree 命 令 。 














$ git write-tree 

9431f4a3f3e1504e03659406faa9529f83cd56f8 

$ git ls-tree -1 9431f4a 

040000 tree 53583ee687fbb2e913d18d508aefd512465b2092 - a 

100644 blob 51dbfd25a804c30e9d8dc441740452534de8264b 34 welcome.txt 





从 上 面 的 命令 中 可 以 看 出 : 


到 处 都 是 40 位 的 SHA1 哈 希 值 格式 的 ID， 可 以 用 于 指 代 文件 内 容 
(blob) 、 目 录 树 (tree) 和 提交 。 但 什么 是 SHA1 哈 希 值 ID， 作 用 是 什 
么 ， 这 些 疑 问 暂时 搁置 ， 下 一 章 再 解答 。 


.命令 pit wtite-ttee 的 输出 就 是 写 入 Git 对 象 库 中 的 TreeID， 这 个 ID 


将 作为 下 一 条 命令 的 输入 。 


` 在 git ls-tree 命 令 中 ， 没 有 把 40 位 的 ID 写 全 ， 而 是 使 用 了 前 几 位 ， 
实际 上 只 要 不 与 其 他 对 象 的 ID 冲突 ， 就 可 以 随心 所 欲 地 使 用 缩写 ID。 


可 以 看 到 gitls-tree 的 输出 显示 的 第 一 条 是 一 个 tree 对 象 ， 即 刚才 创 
建 的 一 级 目 录 a。 


如 休想 要 递归 显示 目录 内 容 ， 则 使 用 -r 参 数 调 用 。 使 用 参数 -t 可 以 
把 递归 过 程 中 遇 到 的 每 标 树 都 显示 出 来 ， 而 不 只 是 显示 最 终 的 文件 。 下 
面 执 行 递归 操作 显示 目录 树 的 内 容 : 








$ git write-tree | xargs git ls-tree -1 -r -t 


©040000 tree 53583ee687fbb2e913d18d508aefd512465b2092 - a 

©040000 tree 514d729095b7bc203cf336723af710d41b84867b - a/b 

©040000 tree deaec688e84302d4a0b98a1b78a434be1b22ca02 - a/b/c 

100644 blob 18832d35117ef2f013c4009f5b2128dfaeff354f 7 a/b/c/hello.txt 
100644 blob 51dbfd25a804c30e9d8dc441740452534de8264b 34 welcome.txt 





好 了 ， 现 在 工作 区 、 和 暂 存 区 和 HEAD 三 个 目录 树 的 内 容 各 不 相同 。 
表 5-1 总 结 了 不 同文 件 在 三 个 目录 树 中 的 文件 大 小 。 





表 5-1 文件 不 同 版 本 的 大 小 


文件 名 
welcome.txt 


a/b/c/hello.txt 





2.Git diff 魔 法 


过 使 用 不 同 的 参数 调用 git diff 命 令 ， 可 以 对 工作 区 、 暂 存 区 和 








HEAD 中 的 内 容 进 行 两 两 比较 。 图 5-2 展 示 了 不 同 的 git diff 命 令 的 作用 范 
围 。 


git diff HEAD 
git diff master 


git diff 





图 5-2 ”git diff 命 令 与 版 本 库 关系 图 
通过 图 5-2 就 不 难 理解 下 面 代码 中 git diff 命 令 的 不 同 输出 结果 了 。 


(1) 工作 区 和 和 暂 存 区 比较 。 








$ git diff 
diff --git a/a/b/c/hello.txt b/a/b/c/hello.txt 
index 18832d3. .e8577ea 100644 
- a/a/b/c/hello.txt 
+++ b/a/b/c/hello.txt 
QQ -1 +1, 2 @@ 
Hello. 
+Bye-Bye. 





(2) 暂 存 区 和 HEAD 比 较 。 





$ git diff --cached 
diff --git a/a/b/c/hello.txt b/a/b/c/hello.txt 


new file mode 100644 
index 0000000. .18832d3 
--- /dev/null 
+++ b/a/b/c/hello.txt 
QQ -0, 0 +1 @@ 
+Hello. 
diff --git a/welcome.txt b/welcome.txt 
index fd3c069..51dbfd2 100644 
--- a/welcome.txt 
+++ b/welcome.txt 
QQ -1, 2 +1, 3 @@ 
Hello. 
Nice to meet you. 
+Bye-Bye. 





(3) 工作 区 和 HEAD 比 较 。 





$ git diff HEAD 
diff --git a/a/b/c/hello.txt b/a/b/c/hello.txt 
new file mode 100644 
index 0000000. .e8577ea 
--- /dev/null 
+++ b/a/b/c/hello.txt 
QQ -0, 0 +1, 2 @@ 
+Hello. 
+Bye-Bye. 
diff --git a/welcome.txt b/welcome.txt 
index fd3c069. .51dbfd2 100644 
--- a/welcome.txt 
+++ b/welcome.txt 
QQ -1, 2 +1, 3 @@ 
Hello. 
Nice to meet you. 
+Bye-Bye. 


ee | 


5.4 不 要 使 用 git commit-a 


实际 上 ，Git 的 提交 命令 (git commit) 可 以 带 上 -a 参 数 ， 对 本 地 所 
有 变更 的 文件 执行 提交 操作 ， 包 括 对 本 地 修改 的 文件 和 删除 的 文件 ， 但 
不 包括 未 被 版 本 库 跟踪 的 文件 。 


这 个 命令 的 确 可 以 简化 一 些 操 作 ， 减 少 用 git add 命 令 标 识 变 更 文件 
的 步骤 ， 但 是 如 果 习 惯 了 使 用 这 个 “偷懒 ”的 提交 人 命令， 融会 丢掉 Git 暂 存 
区 带 给 用 户 的 最 大 好 处 : 对 提交 内 容 进行 控制 的 能 





有 的 用 户 甚 至 通过 别名 设置 功能 将 ci 设置 为 git commit-a， 这 是 更 不 
可 取 的 行为 ， 应 严格 禁止 。 本 书 很 少 会 使 用 git commit-a 命 令 。 


5.5 ”搁置 问题 ， 暂 存 状 态 


查看 一 下 当前 工作 区 的 状态 : 





$ git status 
# On branch master 
# Changes to be committed: 


# (use "git reset HEAD <file>..." to unstage) 

# 

# new file: a/b/c/hello.txt 

# modified: welcome.txt 

# 

# Changes not staged for commit: 

# (use "git add <file>..." to update what will be committed) 
# (use "git checkout -- <file>,..." to discard changes in working directory) 
# 

# 

# 


modified: a/b/c/hello.txt 





在 状态 输出 中 ，Git 体 贴 地 告诉 了 用 户 如 何 将 加 入 暂 存 区 的 文件 从 
暂 存 区 撤 出 以 便 让 暂 存 区 和 HEAD 一 致 ( 这 样 提交 就 不 会 发 生 ) 。 还 告 
诉 用 户 ， 对 于 暂 存 区 更 新 后 在 工作 区 所 做 的 再 一 次 修改 有 两 个 选择 : 或 
者 再 次 添加 到 暂 存 区 ， 或 者 取消 工作 区 新 做 出 的 改动 。 但 是 现在 理解 涉 
及 的 命令 还 有 些 难 度 ， 一 个 是 git reset， 一 个 是 git checkout。 需 要 先 理 解 
什么 是 HEAD， 什 么 是 master 分 支 ， 以 及 Git 对 象 存储 的 实现 机 制 等 问 
题 ， 这 样 才 可 以 更 好 地 操作 暂 存 区 。 








为 此 ， 我 做 出 一 个 非常 艰难 的 决定 : 就 是 保存 当前 的 工作 进度 ， 在 
研究 了 HEAD 和 master 分 支 的 机 制 之 后 ， 继 续 对 暂 存 区 的 探索 。 命 令 git 
stash 就 是 用 于 保存 当前 工作 进度 的 。 








$ git stash 
Saved working directory and index state WIP on master: e695606 which version checkerc 
HEAD is now at e695606 which version checked in? 





运行 完 git stash 之 后 ， 再 查看 工作 区 状态 ， 会 看 见 工作 区 尚未 提交 
的 改动 (包括 暂 存 区 的 改动 》 全 都 不 见 了 。 





$ git status 
# On branch master 
nothing to commit (working directory clean) 





“Tbe back。”( 我 会 再 回来 的 。) 一 一 施 瓦 辛 格 ，《 终 结 者 》， 
1984。 


第 6 章 Git 对 象 


我 们 在 上 一 章 学 习 了 Git 的 一 个 最 重要 的 概念 : 暂 存 区 。 暂 存 区 是 
一 个 介 于 工作 区 和 版 本 库 的 中 间 状 态 ， 当 执行 提交 时 ， 实 际 上 古 将 暂 存 
区 的 内 容 提交 到 版 本 库 中 ， 而 且 Git 的 很 多 命令 都 会 涉及 暂 存 区 的 概 


念 ， 例 如 git diff 命 令 。 








上 一 草 也 留 下 了 很 多 疑惑 ， 例 如 什么 是 HEAD? 什么 是 master? 为 
什么 它们 二 者 〈 在 上 一 章 ) 可 以 相互 蔡 换 使 用 ? 为 什么 Git 中 的 很 多 对 
象 〈“ 如 提交 、 树 、 文 件 内 容 等 ) 都 用 40 位 的 SHA1 哈 希 值 来 表示 ? 本 章 
将 会 揭 开 这 些 奥秘 ， 并 且 还 会 画 出 一 个 更 为 精确 的 版 本 库 结构 图 。 


6.1 Git 对 象 库 探秘 








前 面 刻意 回避 了 对 提交 1D 的 说 明 ， 现 在 是 时 候 来 揭 开 由 40 位 十 六 进 
制 数字 组 成 的 * 魔 弥 数 字 ” 的 奥秘 了 。 


通过 碍 看 日 志 的 详尽 输出 ， 我 们 会 尺 讶 地 看 到 非常 多 的 “魔幻 数 
字 ”， 这 些 “ 魔 幻 数字 ?实际 上 是 SHA1 哈 希 值 。 








$ git 1og -1 --pretty=raw 

commit e695606fc5e31b2ff9038a48a3d363f4c21a3d86 

tree f58da9a820e3fd9d84ab2ca2f1b467ac265038f9 

parent ag0c641e92b10d8bccaled1bf84ca80340fdefee6 

author Jiang Xin <jiangxin@ossxp.com> 1291022581 +0800 

committer Jiang Xin <jiangxin@ossxp.com> 1291022581 +0800 
which version checked in? 








一 个 提交 中 居然 包含 了 三 个 SHA1 哈 希 值 表示 的 对 象 ID: 


* commit e695606fc5e31b2ff9038a48a3d363f4c21a3d86: 这 是 本 次 提交 


的 唯一 标识 。 


' ttee f58da9a820e3fd9d84ab2ca2fl1b467ac265038f9: 这 是 本 次 提交 所 
对 应 的 目录 树 。 


* parent a0c641e92b10d8bccaled1bf84ca80340fdefee6: 这 是 本 地 提交 


的 父 提交 (上 一 次 提交 ) 。 








研究 Git 对 象 ID 的 一 个 重量 级 武器 就 是 git cat-file 命 令 。 用 下 面 的 命 


令 可 以 查看 一 下 这 三 个 ID 的 类 型 。 





$ git cat-file -t e695606 
commit 

$ git cat-file -t f58d 
tree 

$ git cat-file -t a0c6 
commit 





在 引用 对 象 ID 的 时 候 ， 没 有 必要 把 整个 的 40 位 ID 写 全 ， 只 要 从 头 开 
始 的 几 位 不 冲突 即 可 。 


下 面 再 用 git cat-file 命 令 查看 一 下 这 几 个 对 象 的 内 容 。 


， comtmit 对 象 e695606fc5e31b2ff9038a48a3d363f4c21a3d86 





$ git cat-file -p e695606 

tree f58da9a820e3fd9d84ab2ca2f1b467ac265038f9 

parent ag0c641e92b10d8bccaled1bf84ca80340fdefee6 

author Jiang Xin <jiangxin@ossxp.com> 1291022581 +0800 
committer Jiang Xin <jiangxin@ossxp.com> 1291022581 +0800 
which version checked in? 





' tfree 对 象 f58da9a820e3fd9d84ab2ca2f1b467ac265038f9 





$ git cat-file -p f58da9a 
100644 blob fd3c069c1de4f4bc9b15940f490aeb48852f3c42 welcome.txt 





comtmit 对 象 a0c641e92b10d8bccaled1bfg4ca80340fdefee6 





$ git cat-file -p aogc641e 

tree 190d840dd3d8fa319bdec6b8112b0957be7ee769 

parent 9e8a761ff9dd343a1380032884f488a2422c495a 

author Jiang Xin <jiangxin@ossxp.com> 1290999606 +0800 
committer Jiang Xin <jiangxin@ossxp.com> 1290999606 +0800 
who does commit? 





在 上 面 的 目录 树 〈tree) 对 象 中 看 到 了 一 个 新 类 型 的 对 象 : blob 对 
象 ， 这 个 对 象 保存 着 文件 welcome.txt 的 内 容 ， 我 们 用 git cat-file 研 究 一 
下 


” 该 对 象 的 类 型 为 blob。 





$ git cat-file -t fd3c069c1de4f4bc9b15940f490aeb48852f3c42 
blob 





该 对 象 的 内 容 就 是 Welcome.txt 文 件 的 内 容 。 





$ git cat-file -p fd3c069c1de4f4bc9b15940f490aeb48852f3c42 
Hello. 
Nice to meet you. 








这 些 对 象 保存 在 哪里 ? 当然 是 Git 库 中 的 objects 目 录 下 了 (ID 的 前 2 
位 作为 目录 名 ， 后 38 位 作为 文件 名 ) 。 用 下 面 的 命令 可 以 看 到 这 些 对 象 
在 对 象 库 中 的 实际 位 置 。 





$ for id in e695606 f58da9a agc641e fd3c069; do \ 

JS .git/objects/${id:0:2}/${id:2}*; done 
.git/objects/e6/95606fc5e31b2ff9038a48a3d363f4c21a3d86 
.git/objects/f5/8da9a820e3fd9d84ab2ca2f1b467ac265038f9 
.git/objects/a0/c641e92b1i0d8bccaied1ibf84ca80340fdefee6 
.git/objects/fd/3cO69c1ide4f4bc9b15940f490aeb48852f3c42 





图 6-1 更 加 清楚 地 显示 了 Git 对 象 库 中 各 个 对 象 之 间 的 关系 。 


对 象 库 (. git/objects) 


oId e695606 Id: f58da9a Id: fd3c969 
oTree f58da9a 

oparent agc641e 本 | 

oAuthor Jiang Xin Fn welcome txt 


old agc641e 
oTree 190d840 
cparent 9e8a761 





图 6-1 Git 版 本 库 对 象 关 系 图 





过 提交 “Commit) 对 象 之 间 的 相互 关联 ， 可 以 很 容易 地 识别 出 
一 条 跟踪 链 ， 这 条 跟踪 链 可 以 在 运行 git log 命 令 时 通过 --graph 参 数 看 
到 。 下 面 的 命令 还 使 用 了 --pretty=raw 参 数 ， 以 便 显 示 每 个 提交 对 象 的 
parent 属 性 





git log --pretty=raw --graph e695606 

commit e695606fc5e31b2ff9038a48a3d363f4c21a3d86 

tree f58da9a820e3fd9d84ab2ca2f1b467ac265038f9 

parent a0c641e92b10d8bcca1led1bf84ca80340fdefee6 

author Jiang Xin <jiangxin@ossxp.com> 1291022581 +0800 
committer Jiang Xin <jiangxin@ossxp.com> 1291022581 +0800 


which version checked in? 


commit ao0c641e92b10d8bccaled1bf84ca80340fdefee6 

tree 190d840dd3d8fa319bdec6b8112b0957be7ee769 

parent 9e8a761ff9dd343a1380032884f488a2422c495a 

author Jiang Xin <jiangxin@ossxp.com> 1290999606 +0800 
committer Jiang Xin <jiangxin@ossxp.com> 1290999606 +0800 


who does commit? 


+ 一 一 一 一 一 一 一 :+ 一 一 一 一 一 一 一 + 


commit 9e8a761ff9dd343a1380032884f488a2422c495a 
tree 190d840dd3d8fa319bdec6b8112b0957be7ee769 
author Jiang Xin <jiangxin@ossxp.com> 1290919706 +0800 


committer Jiang Xin <jiangxin@ossxp.com> 1290919706 +0800 
initialized. 





最 后 一 个 提交 没有 parent 属 性 ， 所 以 跟踪 链 到 此 终结 ， 这 实际 上 就 
是 提交 的 起 点 。 


现在 来 看 看 HEAD 和 master 的 奥秘 吧 。 


因为 在 上 一 章 的 最 后 执行 了 git stash 命 令 来 将 工作 区 和 和 暂 存 区 的 改 
动 全 部 封存 起 来 ， 所 以 执行 下 面 的 命令 会 看 到 工作 区 和 暂 存 区 中 没有 改 
动 。 











$ git status -s -b 
## master 





说 明 上面 在 显示 工作 区 状态 时 ， 除 了 使 用 了 -s 参 数 以 显示 精简 输 
出 外 ， 还 使 用 了 -b 和 参数， 以 便 能 够 同时 显示 出 当前 工作 分 支 的 名 称 ， 这 
个 -b 参 数 是 在 Git 1.7.2 以 后 加 入 的 新 参数 。 


下 面 的 git branch 是 分 文 管理 的 主要 命令 ， 也 可 以 显示 当前 的 工作 分 
文 。 





$ git branch 
* master 








在 master 分 文 名 称 前 的 星 号 表明 这 个 分 文 是 当前 工作 分 文 。 至 于 为 
什么 没有 其 他 分 文 ， 以 及 什么 叫 分 文 ， 会 在 本 书后 面 的 章节 中 讲解 。 


现在 连续 执行 下 面 的 三 个 命令 会 看 到 相同 的 输出 : 





$ git log -1 HEAD 
commit e695606fc5e31b2ff9038a48a3d363f4c21a3d86 
Author: Jiang Xin <jiangxin@ossxp.com> 
Date: Mon Nov 29 17:23:01 2010 +0800 
which version checked in? 
$ git 1og -1 master 
commit e695606fc5e31b2ff9038a48a3d363f4c21a3d86 
Author: Jiang Xin <jiangxin@ossxp.com> 
Date: Mon Nov 29 17:23:01 2010 +0800 
which version checked in? 
$ git log -1 refs/heads/master 
commit e695606fc5e31b2ff9038a48a3d363f4c21a3d86 
Author: Jiang Xin <jiangxin@ossxp.com> 
Date: Mon Nov 29 17:23:01 2010 +0800 
which version checked in? 








也 就 是 说 ， 在 当前 版 本 库 中 ，HEAD、master 利 refs/heads/master 具 
有 相同 的 指向 。 现 在 到 版 本 库 〈.git 目 录 ) 中 一 探 它们 的 完 竟 。 





$ find .git -name HEAD -0 -name master 
.git/HEAD 

.git/l1ogs/HEAD 
.git/logs/refs/heads/master 
.git/refs/heads/master 





找到 了 4 个 文件 ， 其 中 在 .givlogs 目 录 下 的 文件 稍 后 再 予以 讨论 ， 现 
在 把 目光 锁定 在 .giWHEAD 和 .git/refs/heads/master 上。 


显示 一 下 .giVHEAD 的 内 容 : 





$ cat .git/HEAD 
ref: refs/heads/master 





把 HEAD 的 内 容 翻 译 过 来 就 是 :“ 指 问 一 个 引用 : 
refs/heads/master”"。 这 个 引用 在 哪里 ?当然 是 文件 .git/refs/heads/master 


Tg 


看 看 文件 .git/refs/heads/master 的 内 容 。 





$ cat .git/refs/heads/master 
e695606fc5e31b2ff9038a48a3d363f4c21a3d86 





显示 的 e695606... 所 指 为 何 物 ?可 用 git cat-file 命 令 查 看 。 


(1) 显示 SHA1 哈 希 值 指 代 的 数据 类 型 : 





$ git cat-file -t e695606 
commit 





(2) 显示 该 提交 的 内 容 : 





$ git cat-file -p e695606fc5e31b2ff9038a48a3d363f4c21a3d86 
tree f58da9a820e3fd9d84ab2ca2f1b467ac265038f9 

parent a0c641e92b10d8bccaled1bf84ca80340fdefee6 

author Jiang Xin <jiangxin@ossxp.com> 1291022581 +0800 
committer Jiang Xin <jiangxin@ossxp.com> 1291022581 +0800 
which version checked in? 





原来 分 支 master 指 向 的 是 一 个 提交 ID (最 新 提交 ) 。 这 样 的 分 支 实 
现 是 多 么 的 巧妙 啊 : 既然 可 以 从 任何 提交 开始 建立 一 条 历史 跟踪 链 ， 用 
一 个 文件 指向 这 个 链条 的 最 新 提交 ， 那 么 这 个 文件 就 可 以 用 于 妃 踪 整个 
提交 历史 了 。 这 个 文件 束 是 .gitrefs/heads/master 文 件 。 





下 面 看 一 个 更 接近 于 真实 的 版 本 库 结构 图 ， 如 图 6-2 所 示 。 


tree 
e6956066 Id: fs8da9a 


f58da9a 
oparent a8c6d41e 局 
oAuthor Jiang Xi [welcome txt 


a9c641e 
196d846 





图 6-2 Git 版 本 库 结 构图 


目录 .git/refs 是 保存 引用 的 命名 空间 ， 其 中 .git/refs/heads 目 录 下 的 引 
用 又 称 为 分 文 。 对 于 分 文 ， 既 可 以 使 用 正规 的 长 格式 的 表示 法 ， 如 
refs/heads/master， 也 可 以 去 掉 前 面 的 两 级 目录 用 master 来 表示 。Git 有 一 
个 底层 命令 git rev-parse 可 以 用 于 显示 引用 对 应 的 提交 ID。 








$ git rev-parse master 
e695606fc5e31b2ff9038a48a3d363f4c21a3d86 
$ git rev-parse refs/heads/master 
e695606fc5e31b2ff9038a48a3d363f4c21a3d86 
$ git rev-parse HEAD 
e695606fc5e31b2ff9038a48a3d363f4c21a3d86 


可 以 看 出 它们 都 指向 同一 个 对 象 。 为 什么 这 个 对 象 是 40 位 ， 而 不 是 
更 少 或 更 多 ? 这 些 古 是 如 何 生成 的 呢 ? 


6.2 思考: SHA1 哈 希 值 到 底 是 什么 ， 是 如 何 生成 
的 


哈 希 (hash〉 中 是 一 种 数据 摘要 算法 (或 称 散 列 算法 ) ， 是 信息 安 
全 领域 中 重要 的 理论 基石 。 该 算法 将 任意 长 度 的 输入 经 过 散 列 运算 转换 
为 固定 长 度 的 输出 。 固 定 长 度 的 输出 可 以 称 为 对 应 输入 内 容 的 数字 摘要 
或 哈 希 值 。 例 如 SHA1 摘 要 算法 可 以 处 理 从 零 到 两 百 多 万 TB〈 注 : 264 -1 
比特 ， 相 当 于 209 万 TB。1TB 相 当 于 1024GB。) 的 输入 数据 ， 输 出 为 固 
定 的 160 比 特 的 数字 摘要 。 即 使 两 个 不 同 内 容 的 输入 数据 量 非常 大 、 差 
异 非 常 小 ， 两 者 的 哈 希 值 也 会 显 车 不同。 比较 著名 的 摘要 算法 有 : MD5 
和 SHA1。Linux 下 shalsum 命 令 可 以 用 于 生成 摘要 。 





$ printf Git |shalsum 
5819778898df55e3a762f0c5728b457970d72cae - 


可 以 看 出 字符 串 Git 的 SHA1 哈 希 值 由 40 个 十 六 进 制 的 数字 组 成 。 那 
么 能 不 能 找 出 另外 一 个 字符 串 使 其 SHA1 哈 希 值 和 上 面 的 哈 希 值 一 样 
呢 ? 下 面 来 看 看 难度 有 多 大 。 





每 个 十 六 进 制 的 数字 相当 于 一 个 4 位 的 二 进 制 数字 ， 因 此 40 位 的 
SHA1 哈 希 值 的 输出 实际 为 160 比 特 。 拿 双色 球 博 彩 打 一 个 比喻 ， 要 想 制 
造 相同 的 SHA1 哈 希 值 就 相当 于 要 选 出 32 个 喇 “ 红 色 球 ”， 每 个 红 球 有 1 到 


32 个 (5 位 的 三 进 制 数 字 )〉 选择 ， 不 但 红 球 之 间 可 以 重复 ， 而 且 选 出 红 
球 的 顺序 必须 一 致 。 相 比 “ 双 色 球 博彩 ”总 共 只 须 选 出 6 颗 红 球 〈1 到 33) 
外 加 1 个 篮球 〈1 到 16) ，SHA1“ 中 奖 ” 的 难度 差不多 相当 于 要 连续 购买 
七 期 中 “双色 球 ? 并 且 每 一 期 都 必需 中 一 等 奖 。 当 然 由 于 算法 上 的 问题 ， 
制造 冲突 《相同 数字 摘要 ) 的 几率 没有 那么 小 向 ， 但 是 已 经 足够 小 

了 ， 能 够 满足 Git 对 不 同 的 对 象 进行 区 分 和 标识 了 。 即 使 有 一 天 像 发 现 
了 类 似 MD5 摘 要 算法 的 冲突 那样 ， 发 现 了 SHA1 算 法 存在 人 为 制造 冲突 
的 可 能 ， 那 么 Git 可 以 使 用 更 为 安全 的 SHA-256 或 SHA-512 的 摘要 算法 。 


可 是 Git 中 的 各 种 对 象 ， 提交 (commit) 、 文 件 内 容 (blob) 、 目 录 
树 (tree)〉 等 中 I， 其 对 应 的 SHA1 哈 希 值 是 如 何 生 成 的 呢 ? 下 面 就 来 展 


A 一下。 





先 看 一 看 提交 的 SHA1 哈 希 值 生成 方法 。 


(1) 看 看 HEAD 对 应 的 提交 的 内 容 ， 使 用 git cat-file 命 令 。 





$ git cat-file commit HEAD 

tree f58da9a820e3fd9d84ab2ca2f1b467ac265038f9 

parent agc641e92b10d8bccaled1bf84ca80340fdefee6 

author Jiang Xin <jiangxin@ossxp.com> 1291022581 +0800 
committer Jiang Xin <jiangxin@ossxp.com> 1291022581 +0800 
which version checked in? 








(2) 提交 信息 中 总 共 包 含 234 个 字符 。 





$ git cat-file commit HEAD | wc -c 
234 





(3) 在 提交 信息 的 前 面 加 上 内 容 commit 234<null> (<null> 为 空 字 
符 ) ， 然 后 执行 SHA1 哈 希 算法 。 





$ ( printf "commit 234\000"; git cat-file commit HEAD ) | shalsum 
e695606fc5e31b2ff9038a48a3d363f4c21a3d86 





(4) 上 面 命令 得 到 的 哈 希 值 和 用 git rev-parse 看 到 的 是 一 样 的 。 





$ git rev-parse HEAD 
e695606fc5e31b2ff9038a48a3d363f4c21a3d86 








下 面 来 看 一 看 文件 内 容 的 SHA1 哈 希 值 生 成 方法 。 


(1) 看 看 版 本 库 中 welcome.txt 的 内 容 ， 使 用 git cat-file 命 令 。 





$ git cat-file blob HEAD:welcome.txt 
Hello. 
Nice to meet you. 





(2) 文件 总 共 包含 25 字 节 的 内 容 。 





$ git cat-file blob HEAD:welcome.txt | wc -c 
25 





(3) 在 文件 内 容 的 前 面 加 上 blob 25<null> 的 内 容 ， 然 后 执行 SHA1 
哈 希 算法 。 





$ ( printf "blob 25\000"; git cat-file blob HEAD:welcome.txt ) | shalsum 
fd3co69c1ide4f4bc9b15940f490aeb48852f3c42 





(4) 上 面 的 命令 得 到 的 哈 希 值 和 用 git rev-parse 看 到 的 是 一 样 的 。 





$ git rev-parse HEAD:welcome,.txt 
fd3co69c1ide4f4bc9b15940f490aeb48852f3c42 








最 后 再 来 看 看 树 的 SHA1 哈 希 值 的 形成 方法 。 


(1) HEAD 对 应 的 树 的 内 容 共 包含 39 个 字 市 。 





$ git cat-file tree HEAD^{tree} | wc -c 
39 





(2) 在 树 的 内 容 的 前 面 加 上 tree 39<null> 的 内 容 ， 然 后 执行 SHA1 
哈 希 算法 。 





$ ( printf "tree 39\000"; git cat-file tree HEAD^{tree} ) | shaisum 
f58da9a820e3fd9d84ab2ca2f1b467ac265038f9 - 





(3) 上 面 的 命令 得 到 的 哈 希 值 和 用 git rev-parse 看 到 的 是 一 样 的 。 





$ git rev-parse HEAD^{tree} 
f58da9a820e3fd9d84ab2ca2f1b467ac265038f9 





后 面 在 学 习 里 程 碑 〈Tag) 的 时 候 会 看 到 ，Tag 对 象 〈 轻 量 级 Tag 除 
外 ) 也 是 采用 类 似 的 方法 在 对 象 库 中 存储 的 。 








[1] http:/ /en.wikipedia.org/wiki/ Cryptographic_hash_function#cite_ref-13 


[2] 160 比 特 分 成 32 组 ， 每 组 5 个 比特 。 


[3] 160 二 24 一 6.6 
[和 相当 于 连续 购买 两 期 双色 球 彩 票 且 都 中 一 等 奖 。 


[5] 还 有 tag 对 象 ， 参 见 第 3 篇 第 17.2.2 节 。 





6.3 思考 :为 什么 不 用 顺序 的 数字 来 表示 提交 


到 目前 为 止 所 进行 的 提交 都 是 顺序 提交 ， 这 可 能 会 让 您 产生 这 人 么 一 
个 想法 ， 为 什么 Git 的 提交 不 依据 提交 顺序 对 提交 进行 编号 呢 ? 可 以 把 
第 一 次 提交 定义 为 提交 1， 依 次 递增 。 尤 其 是 对 于 拥有 像 Subversion 等 集 
中 式 版 本 控制 系统 使 用 经 验 的 用 户 而 言 ， 更 会 有 这 样 的 体会 和 想法 。 











集中 式 版 本 控制 系统 因为 只 有 一 个 集中 式 的 版 本 库 ， 所 以 可 以 很 容 
易 地 实现 依次 递增 的 全 局 唯一 的 提交 号 ， 像 Subversion 束 古 如 此 。Git 作 
为 分 布 式 版 本 控制 系统 ， 开 及 可 以 是 非 线性 的 ， 每 个 人 痢 可 以 通过 克隆 
版 本 库 的 方式 工作 在 不 同 的 本 地 版 本 库 当 中 ， 在 本 地 做 的 提交 可 以 通过 
版 本 库 之 间 的 交互 《推送 和 拉 回 操作 ) 而 互相 分 发 ， 如 果 提 区 采 用 本 地 
唯一 的 数字 编写 ， 在 提交 分 发 的 时 候 会 不 可 避免 地 造成 冲突 。 这 就 要 求 
提交 的 编号 不 能 仅仅 是 本 地 局 部 有 效 ， 而 是 要 “全 球 唯一 "。Git 的 提交 通 
过 SHA1 哈 希 值 作为 提交 ID， 的 确 做 到 了 “全 球 唯一 ”。 











Mercurial (Hg) 是 男 外 一 个 着 名 的 分 布 式 版 本 控制 系统 ， 它 的 提交 
ID 非常 有 趣 : 同时 使 用 了 顺序 的 数字 编写 和 “全 球 唯一 ”的 SHA1 哈 希 
值 。 但 实际 上 顺序 的 数字 编号 只 是 本 地 有 效 ， 对 于 克隆 版 本 库 来 说 没有 
意义 ， 只 有 SHA1 哈 希 值 才 是 通用 的 编号。 下面 来 看 一 个 Hg 的 示例 : 





$ hg 1og --limit 2 
修改 集 : 3009:2f1a3a7e8eb0 





tip 

Daniel Neuhuser <dasdasich@gmail.com> 
Wed Dec 01 23:13:31 2010 +0100 
"Fixed" the CombinedHTMLDiff test 
3008:2fd3302car7e5 

Daniel Neuhuser <dasdasich@gmail.com> 
Wed Dec 01 22:54:54 2010 +0100 

#559 Add ‘html permalink_ text confval 
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Hg 的 设计 使 得 在 本 地 使 用 版 本 库 更 为 方便 ， 但 是 要 在 Git 中 做 类 似 
实现 却 很 难 ， 这 是 因为 Git 相 比 Hg 拥 有 真正 的 分 文 管理 功能 。 在 Git 中 会 
存在 当前 分 文中 看 不 到 的 其 他 分 支 的 提交 ， 如 何 管理 提交 编号 十 


水 : 





分 复 


笠 好 Git 提 供 了 很 多 方法 可 以 方便 地 访问 Git 库 中 的 对 象 : 


` 采用 部 分 的 SHA1 哈 希 值 。 不 必 把 40 位 的 哈 希 值 写 全 ， 只 采用 开 
头 的 部 分 (4 位 以 上 ) ， 只 要 不 与 现 有 的 其 他 哈 希 值 冲 突 即 可 。 


. 使 用 mastet 代 表 分 支 mastet 中 最 新 的 提交 ， 也 可 以 使 用 全 称 


tefs/heads/mastet 或 heads/mastet。 
` 使 用 HEAD 代 表 版 本 库 中 最 近 的 一 次 提交 。 
. 符号 ^ 可 以 用 于 指 代 父 提交 。 例 如 : 


. HEAD^ 代 表 版 本 库 中 的 上 一 次 提交 ， 即 最 近 一 次 提交 的 父 提 


. HEAD^^ 则 代表 HEAD^ 的 父 提 交 。 


. 对 于 一 个 提交 有 多 个 父 提交 ， 可 以 在 符号 ^ 后 面 用 数字 表示 是 第 


几 个 父 提 交 。 例 如 : 


. a573106^2 的 含义 是 提交 a573106 的 多 个 父 提交 中 的 第 二 个 父 提 


. HEAD^1 相 当 于 HEAD^， 含 义 是 HEAD 的 多 个 父 提交 中 的 第 一 


个 父 提 交 。 


. HEADA^^2 的 含义 是 HEAD^ (HEAD 父 提交 ) 的 多 个 父 提 交 中 


的 第 二 个 父 提 交 。 


. 符号 ~ 也 可 以 用 于 指 代 祖 先 提交 。 例 如 : 


a573106~5 即 相当 于 a573106AAAAA。 


` 提交 所 对 应 的 树 对 象 ， 可 以 用 类 似 如 下 的 语法 访问 : 


a573106A{ftree} 


某 一 次 提交 对 应 的 文件 对 象 ， 可 以 用 如 下 的 语法 访问 : 


a573106:path/to/file 


* 暂 存 区 中 的 文件 对 象 ， 可 以 用 如 下 的 语法 访问 : 


:path/to/file 


您 可 以 使 用 git rev-parse 命 令 在 本 地 版 本 库 中 练习 一 下 : 





$ git rev-parse HEAD 
e695606fc5e31b2ff9038a48a3d363f4c21a3d86 

$ git cat-file -p e695 

tree f58da9a820e3fd9d84ab2ca2f1b467ac265038f9 

parent a0c641e92b10d8bccaled1bf84ca80340fdefee6 

author Jiang Xin <jiangxin@ossxp.com> 1291022581 +0800 
committer Jiang Xin <jiangxin@ossxp.com> 1291022581 +0800 
which version checked in? 

$ git cat-file -p e695^ 

tree 190d840dd3d8fa319bdec6b8112b0957be7ee769 

parent 9e8a761ff9dd343a1380032884f488a2422c495a 

author Jiang Xin <jiangxin@ossxp.com> 1290999606 +0800 
committer Jiang Xin <jiangxin@ossxp.com> 1290999606 +0800 
who does commit? 

$ git rev-parse e695^{tree} 
f58da9a820e3fd9d84ab2ca2f1b467ac265038f9 

$ git rev-parse e695^^{tree} 
190d840dd3d8fa319bdec6b8112b0957be7ee769 





在 本 篇 的 第 11.4.1 小 节 中 ， 还 会 讲解 更 多 访问 Git 对 象 的 技巧 ， 例 如 
使 用 tag 和 日 期 来 访问 版 本 库 对 象 。 


第 7 章 ”Git 重 置 


上 一 章 讲 解 了 版 本 库 中 对 象 的 存储 方式 ， 以 及 分 文 master 的 实现 。 
即 master 分 支 在 版 本 库 的 引用 目录 .git/refs〉 中 体现 为 一 个 引用 文 
件 .git/refs/heads/master， 其 内 容 就 是 分 支 中 最 新 提交 的 提交 ID。 














$ cat .git/refs/heads/master 
e695606fc5e31b2ff9038a48a3d363f4c21a3d86 











上 一 半 还 通过 对 提交 本 里 数据 结构 的 分 析 看 到 ， 提 交 可 以 通过 对 父 
提交 的 关联 实现 对 提交 历史 的 追溯 。 注意 ， 下 面 的 git log 命 令 中 使 用 了 - 
-oneline 参 数 ， 类 似 于 --pretty=oneline， 但 是 可 以 显示 更 短小 的 提交 ID。 
参数 --oneline 在 Git 1.6.3 及 以 后 的 版 本 中 才 有 ， 老 版 本 的 Git 可 以 使 用 参 


数 --pretty=oneline--abbrev-commit 蔡 代 。 











$ git 1og --graph --oneline 

* e695606 which version checked in? 
* 8a0c641e who does commit? 

* 9e8a761 initialized. 





那么 ， 是 不 是 有 新 的 提交 发 生 的 时 候 ，master 分 支 对 应 的 引用 文件 
中 的 内 容 就 会 改变 呢 ? master 分 文 对 应 的 引用 文件 中 的 内 容 可 以 人 为 地 
改变 吗 ? 本 章 就 来 探讨 如 何 用 git reset 命 令 改变 分 支 引用 文件 的 内 容 ， 即 
实现 分 支 的 重 置 。 





7.1 分 文 游标 master 探 秘 





先 来 看 看 当 有 新 的 提交 发 生 的 时 候 ， 文 件 .git/refs/heads/master 的 内 
容 如 何 改变 。 首 先 在 工作 区 创建 一 个 新 文件 ， 姑 且 叫 作 new- 
commit.txt， 然 后 提交 到 版 本 库 中 。 





$ touch new-commit .txt 

$ git add new-commit ,txt 

$ git commit -m "does master follow this new commit?" 
[master 4902dc3] does master follow this new commit? 
9 files changed, 0 insertions(+), © deletions(-) 
create mode 100644 new-commit.txt 











此 时 工作 目录 下 会 有 两 个 文件 ， 其 中 文件 new-commit.txt 是 新 增 
的 





$ 1s 
new-commit.txt welcome.txt 








来 看 看 master 分 支 指 同 的 提交 有 DD 是否 改变 了 。 


. 可 以 看 出 在 版 本 库 引 用 空间 (.git/refs/ 目 录 ) 下 的 master 文 件 内 
容 的 确 改 变 了 ， 指 向 了 新 的 提交 。 





$ cat .git/refs/heads/master 
4902dc375672fbf52a226e0354100b75d4fe31e3 





再 用 gitlog 查 看 一 下 提交 日 志 ， 可 以 看 到 刚刚 完成 的 提交 。 





$ git 1og --graph --oneline 

* 4902dc3 does master follow this new commit? 
* e695606 which version checked in? 

* 8a0c641e who does commit? 

* 9e8a761 initialized. 





引用 refs/heads/master 就 好 像 是 一 个 游标 ， 在 有 新 的 提交 发 生 的 时 候 
指向 了 新 的 提交 。 可 是 如 果 只 可 上 、 不 可 下 ， 就 不 能 称 为 “游标 ?。Git 提 
供 了 git reset 命 令 ， 可 以 将 “游标 ?指向 任意 一 个 存在 的 提交 ID。 下 面 的 示 
例 就 尝试 人 为 地 更 改 游标 。( 注 意 下 面 的 命令 中 使 用 了 --hard 参 数 ， 会 
破坏 工作 区 未 提交 的 改动 ， 慎 用 。) 








$ git reset --hard HEAD^ 
HEAD is now at e695606 which version checked in? 





还 记得 上 一 章 介绍 的 HEADA^A 代 表 了 HEAD 的 父 提 交 吗 ? 这 条 命令 就 
相当 于 将 master 重 置 到 上 一 个 老 的 提交 上 。 我 们 来 看 一 下 master 文 件 的 
内 容 是 个 更 改 了 。 





$ cat .git/refs/heads/master 
e695606fc5e31b2ff9038a48a3d363f4c21a3d86 





果然 ，master 分 支 的 引用 文件 的 指 同 更 改 为 前 一 次 提交 的 ID 了 ， 而 
且 通 过 下 面 的 命令 可 以 看 出 新 添加 的 文件 new-commit.txt 也 丢失 了 。 





$ 1s 
welcome.txt 








重 置 命令 不 仅 可 以 重 置 到 前 一 次 提交 ， 而 且 还 可 以 直接 使 用 提交 ID 


重 置 到 任何 一 次 提交 。 


(1) 通过 git log 碍 询 到 最 早 的 提交 ID。 





git log --graph --oneline 

e695606 which version checked in? 
a0c641e who does commit? 

9e8a761 initialized. 


+ * *{ 








(2) 然后 重 置 到 最 早 的 一 次 提交 。 





$ git reset --hard 9e8a761 
HEAD is now at 9e8a761 initialized. 








(3) 重 置 后 会 发 现 welcome.txt 也 回 退 到 原始 版 本 库 ， 曾 经 的 修改 
都 丢失 了 。 





$ cat welcome.txt 
Hello. 





使 用 重 置 命令 很 危险 ， 会 彻底 地 丢 痉 历史 。 那 么 ， 还 能 够 通过 浏览 
提交 历史 的 办 法 找到 丢弃 的 提交 ID， 再 使 用 重 置 命令 恢复 历史 吗 ? 不 可 
能 ! 因为 重 置 让 提交 历史 也 改变 了 ， 提 交 日 志 如 下 : 








$ git 1og 

commit 9e8a761ff9dd343a1380032884f488a2422c495a 

Author: Jiang Xin <jiangxin@ossxp.com> 

Date: Sun Nov 28 12:48:26 2010 +0800 
initialized. 





7.2 ”用 reflog 挽 救 错 误 的 重 置 


如 果 没 有 记 下 重 置 前 master 分 文 指 同 的 提交 ID， 想 要 重 置 回 原来 的 
提交 似乎 是 一 件 麻烦 的 事情 (去 对 象 库 中 一 个 一 个 地 找 )。 焉 好 Git 提 
供 了 一 个 挽救 机 制 ， 通 过 .git/logs 目 录 下 日 志文 件 记录 了 分 支 的 变更 。 
默认 非 裸 版 本 库 《〈 带 有 工作 区 ) 都 提供 分 支 日 志 功 能 ， 这 是 因为 带 有 工 
作 区 的 版 本 库 都 有 如 下 设置 : 








$ git config core.logallrefupdates 
true 





查看 一 下 master 分 支 的 日 志文 件 .git/logs/refs/heads/master 中 的 内 容 。 
下 面 的 命令 显示 了 该 文件 的 最 后 几 行 。 为 了 排版 的 需要 ， 还 将 输出 中 的 
40 位 的 SHA1 提 交 ID 缩 短 。 





$ tail -5 .git/logs/refs/heads/master 

dca47ab a0c641e Jiang Xin <...> 1290999606 +0800 commit (amend): who does commit? 
ao0c641e e695606 Jiang Xin 
e695606 4902dc3 Jiang Xin 
4902dc3 e695606 Jiang Xin 
e695606 9e8a761 Jiang Xin 


...> 1291022581 +0800 commit: which version checked in? 
...> 1291435985 +0800 commit: does master follow ... 
...> 1291436302 +0800 HEAD^: updating HEAD 


< 
< 
< 
<...> 1291436382 +0800 9e8a761: updating HEAD 





可 以 看 出 这 个 文件 记录 了 master 分 支 指向 的 变迁 ， 最 新 的 改变 追加 
到 文件 的 末尾 ， 因 此 最 后 出 现 。 最 后 一 行 可 以 看 出 因为 执行 了 git reset-- 
hard 命 令 ， 指 向 的 提交 ID 由 e695606 改 变 为 9e8a761。 


Git 提 供 了 一 个 git reflog 命 令 ， 对 这 个 文件 进行 操作 。 使 用 show 子 命 
令 可 以 显示 此 文件 的 内 容 。 





$ git reflog show master | head -5 

9e8a761 master@{0}: 9e8a761: updating HEAD 

e695606 master@{1}: HEAD^: updating HEAD 

4902dc3 master@{2}: commit: does master follow this new commit? 
e695606 master@{3}: commit: which version checked in? 

a0c641e master@{4}: commit (amend): who does commit? 














查看 git reflog 的 输出 和 直接 查看 日 志文 件 最 大 的 不 同 在 于 显示 顺序 
的 不 同 ， 即 最 新 改变 放 在 了 最 前 面 显 示 ， 而 且 只 显示 每 次 改变 的 最 终 的 
SHA1 哈 希 值 。 还 有 个 重要 的 区 别 在 于 git reflog 命 令 的 输出 中 还 提供 了 一 
个 方便 易 记 的 表达 式 : <refname>@{<n>}。 这 个 表达 式 的 含义 是 引用 
<refname> 之 前 第 <n> 次 改变 时 的 SHA1 哈 希 值 。 








那么 将 引用 master 切 换 到 两 次 变更 之 前 的 值 ， 可 以 使 用 下 面 的 命 


. 重 置 mastet 为 两 次 改变 之 前 的 值 。 





$ git reset --hard master@{2} 
HEAD is now at 4902dc3 does master follow this new commit? 





. 重 置 后 工作 区 中 的 文件 new-commit.txt 又 回来 了 。 





$ 1s 
nNew-commit.txt welcome.txt 





. 提交 历史 也 回来 了 。 





$ git 1og --oneline 

4902dc3 does master follow this new commit? 
e695606 which version checked in? 

ao0c641e who does commit? 

9e8a761 initialized. 





此 时 如 果 再 用 git reflog 查 看 ， 会 看 到 恢复 master 的 操作 也 记录 在 日 
志 中 了 。 





$ git reflog show master | head -5 

4902dc3 master@{0}: master@{2}: updating HEAD 

9e8a761 master@{1}: 9e8a761: updating HEAD 

e695606 master@{2}: HEAD^: updating HEAD 

4902dc3 master@{3}: commit: does master follow this new commit? 
e695606 master@{4}: commit: which version checked in? 





7.3 深入 了 解 git reset 命 令 





重 置 命令 〈git reset) 是 Git 最 常用 的 命令 之 一 ， 也 是 最 危险 最 容易 


误 用 的 命令 。 来 看 看 git reset 命 令 的 用 法 。 











用 法 一 : git reset [-q] [<commit>] [--] <paths>... 
用 法 二 : git reset [--soft | --mixed | --hard | --merge | --keep] [-q] [<commit>] 




















上 面 列 出 了 两 个 用 法 ， 其 中 <commit> 都 是 可 选项 ， 可 以 使 用 引用 或 
提交 ID， 如 果 省 略 <commit> 则 相当 于 使 用 了 HEAD 的 指 同 作为 提交 ID。 


上 面 列 出 的 两 种 用 法 的 区 别 在 于 ， 第 一 种 用 法 在 命令 中 包含 路 径 
<paths>。 为 了 避免 路 径 和 引用 《或 者 提交 ID) 同名 而 发 生 冲 突 ， 可 以 
在 <paths> 前 用 两 个 连续 的 短线 ( 减 写 ) 作为 分 隔 。 


第 一 种 用 法 (包含 了 路 径 <paths> 的 用 法 ) 不 会 重 置 引 用 ， 更 不 会 
改变 工作 区 ， 而 是 用 指定 提交 状态 (<commit>〉 下 的 文件 (<paths>) 
替换 掉 暂 存 区 中 的 文件 。 例 如 命令 git reset HEAD<paths> 相 当 于 取消 之 
前 执行 的 git add<paths> 命 令 时 改变 的 暂 存 区 。 


第 二 种 用 法 (不 使 用 路 径 <paths> 的 用 法 ) 则 会 重 置 引 用 。 根 据 不 
同 的 选项 ， 可 以 对 暂 存 区 或 工作 区 进行 重 置 。 参 照 下 面 的 版 本 库 模 型 图 
(图 7-1) ， 来 看 一 看 不 同 的 参数 对 第 二 种 重 置 语法 的 影响 。 











图 7-1 重 置 命令 与 版 本 库 关 系 图 





命令 格式 : git reset [--soft | --mixed | --hard ] [<commit>] 





. 使 用 参数 --hard， 如 : gait reset--hatrd<commit> 。 


会 执行 上 图 中 的 全 部 动作 di、 包 、 包 ， 即 : 


@@ 替 换 引用 的 指向 。 引 用 指向 新 的 提交 ID 


包 蔡 换 暂 存 区 。 蔡 换 后 ， 暂 存 区 的 内 容 和 引用 指向 的 目录 树 一 致 。 





@@ 蔡 换 工 作 区 。 蔡 换 后 ， 工 作 区 的 内 容 变 得 和 和 暂 存 区 一 致 ， 也 和 
HEAD 所 指向 的 目录 树 内 容 相 同 。 





` 使 用 参数 --soft， 如 : git reset--soft<commit>。 


会 执行 上 图 中 的 操作 (D。 即 只 更 改 引 用 的 指向 ， 不 改变 暂 存 区 和 工 


作 区 。 


` 使 用 参数 --mixed 或 不 使 用 参数 〈 默 认为 --mixed) ， 如 : git 


reset<commit> 。 





会 执行 上 图 中 的 操作 (和 操作 己 。 即 更 改 引 用 的 指 癌 及 重 置 暂 存 
区 ， 但 是 不 改变 工作 区 。 


下 面 通 过 一 些 示 例 ， 看 一 下 重 置 命 令 的 不 同 用 法 。 
` 命令 : git reset 


仅 用 HEAD 指 向 的 目录 树 重 置 暂 存 区 ， 工 作 区 不 会 受到 影响 ， 相 当 
于 将 之 前 用 git add 命 令 更 新 到 和 暂 存 区 的 内 容 撤 出 暂 存 区 。 引 用 也 未 改 
变 ， 因 为 引用 重 置 到 HEAD 相 当 于 没有 重 置 。 








` 命令 : git reset HEAD 
同上 。 
` 命令 : git reset--filename 


仅 将 文件 filename 的 改动 撤 出 暂 存 区 ， 暂 存 区 中 其 他 文件 不 改变 。 
相当 于 对 命令 git add filename 的 反 向 操作 。 


` 命令 : git reset HEAD filename 


同上 。 


` 命令 : git reset--soft HEAD^ 








工作 区 和 和 暂 存 区 不 改变 ， 但 是 引用 向 前 回 退 一 次 。 当 对 最 新 提交 的 
提交 说 明 或 提交 的 更 改 不 满意 时 ， 撤 销 最 新 的 提交 以 便 重 新 提交 。 





在 之 前 曾经 介绍 过 一 个 修补 提交 命令 git commit--amend， 用 于 对 最 
新 的 提交 进行 重新 提交 以 修补 错误 的 提交 说 明 或 错误 的 提交 文件 。 修 补 
提交 命令 实际 上 相当 于 执行 了 下 面 两 条 命令 。( 注 : 文 
件 .giWCOMMIT_EDITMSG 保 存 了 上 次 的 提交 日 志 。) 











$ git reset --soft HEAD^ 
$ git commit -e -F .git/COMMIT_EDITMSG 





命令: git reset HEAD^ 





工作 区 不 改变 ,但 是 暂 存 区 会 回 退 到 上 一 次 提交 之 前 ， 引 用 也 会 回 


二 
` 命令: git teset--mixed HEAD”^ 
同上 。 
` 命令 : git reset--hard HEAD”^ 


彻底 撤销 最 近 的 提交 。 引 用 回 退 到 前 一 次 ， 而 且 工作 区 和 和 暂 存 区 都 








会 回 退 到 上 一 次 提交 的 状态 。 自 上 一 次 以 来 的 提交 全 部 丢失 。 


第 8 章 ”Git 检 出 


在 上 一 章 我 们 学 习 了 重 置 命 令 (git reset) 。 重 置 命 令 的 一 个 用 途 就 
是 修改 引用 (如 master〉 的 游标 指向 。 实 际 上 在 执行 重 置 命 令 的 时 候 没 
有 使 用 任何 参数 对 所 要 重 置 的 分 支 名 《如 master) 进行 设置 ， 这 是 因为 
重 置 命令 实际 上 所 针对 的 是 头 指 针 HEAD。 之 所 以 重 置 命令 没有 改变 头 
旨 针 HEAD 的 内 容 ， 是 因为 HEAD 指 癌 了 一 个 引用 refs/heads/master， 上 所 
以 重 置 命令 体现 为 分 支 “ 游 标 ” 的 变更 ，HEAD 本 身 一 直 指 向 的 是 
refs/heads/master， 并 没有 在 重 置 时 改变 。 








如 果 HEAD 的 内 容 不 能 改变 而 一 直 都 指向 master 分 支 ， 那 么 Git 如 此 
精妙 的 分 支 设计 岂 不 是 浪费 ? 如 果 HEAD 要 改变 该 如 何 改变 呢 ? 本 章 将 
学 习 检 出 命令 〈git checkout) ， 该 命令 的 实质 就 是 修改 HEAD 本 和 丑 的 指 


问 ， 该 命令 不 会 影响 分 支 “游标 ”( 如 master) 。 





8.1 _ HEAD 的 重 置 即 检 出 


HEAD 可 以 理解 为 “ 头 指针 ”， 是 当前 工作 区 的 “基础 版 本 >”， 当 执行 
提交 时 ，HEAD 指 同 的 提交 将 作为 新 提交 的 父 提交 。 看 看 当前 HEAD 的 
指 问 。 








$ cat .git/HEAD 
ref: refs/heads/master 





可 以 看 出 HEAD 指 向 了 分 支 master。 此 时 执行 git branch 会 看 到 当前 
处 于 master 分 支 。 





$ git branch -v 
* master 4902dc3 does master follow this new commit? 





现在 使 用 git checkout 命 令 检 出 该 ID 的 父 提交 ， 看 看 会 怎样 。 





$ git checkout 4902dc3^ 

Note: checking out '4902dc3^ ' ， 

You are in 'detached HEAD' state. You can look around, make experimental 

changes and commit them, and you can discard any commits you make in this 

state without impacting any branches by performing another checkout. 

If you want to create a new branch to retain commits you create, you may 

do so (now or later) by using -b with the checkout command again. Example: 
git checkout -b new_branch_name 

HEAD is now at e695606.,... which version checked in? 





出 现 了 大 段 的 输出 ! 翻译 一 下 ，Git 肯 定义 在 提醒 我 们 了 。 





checkout 4902dc3^ 


$ git 
意 : 正 检 出 '4902dc3^' ， 


注意 











您 现在 处 于 “分 离 头 指针 ′ 状态 。 您 可 以 检查 、 测 试 和 提交 ， 而 不 影响 任何 分 支 。 

通过 执行 另外 的 一 个 checkout 检 出 指令 会 丢弃 在 此 状态 下 的 修改 和 提交 

如 果 想 保留 在 此 状态 下 的 修改 和 提交 ， 使 用 -b 参数 调用 checkout 检 出 ' 指 令 以 

创建 新 的 跟踪 分 文 。 如 ; 
git checkout -b new_branch_name 

头 指针 现在 指向 e695606.. ， 提 交 说 明 为 : which version checked in? 










































































什么 叫 作 ”“ 分 离 头 指针 ?状态 ? 碍 看 一 下 此 时 HEAD 的 内 容 就 明白 
可 





$ cat .git/HEAD 
e695606fc5e31b2ff9038a48a3d363f4c21a3d86 





原来 “分 离 头 指针 ?状态 指 的 就 是 HEAD 头 指针 指向 了 一 个 具体 的 提 
交 ID， 而 不 是 一 个 引用 《分 文 ) 。 


查看 最 新 提交 的 reflog 也 可 以 看 到 当 针 对 提交 执行 git checkout 命 令 
时 ，HEAD 头 指针 被 更 改 了 : 由 指 同 master 分 文 变 成 了 指 癌 一 个 提交 
ID 。 





$ git reflog -1 
e695606 HEAD@{0}: checkout: moving from master to 4902dc3A^ 








注意 上 面 的 reflog 是 HEAD 头 指针 的 变迁 记录 ， 而 非 master 分 文 。 


查看 一 下 HEAD 和 master 对 应 的 提交 ID， 会 发 现 现在 它们 指向 的 不 
一 样 。 





$ git rev-parse HEAD master 
e695606fc5e31b2ff9038a48a3d363f4c21a3d86 
4902dc375672fbf52a226e0354100b75d4fe31e3 





前 一 个 是 HEAD 头 指针 的 指 癌 ， 后 一 个 是 master 分 文 的 指向 。 而 且 
还 可 以 看 到 执行 git checkout 命 令 与 执行 git reset 命 令 不 同 ， 分 文 
(master〉 的 指 同 并 没有 改变 ， 仍 旧 指 向 原 有 的 提交 ID。 


现在 版 本 库 的 HEAD 是 指向 e695606 提 交 的 。 再 做 一 次 提交 ，HEAD 
会 如 何 变化 呢 ? 具体 操作 过 程 如 下 。 





(1) 先 做 一 次 修改 : 创建 一 个 新 文件 detached-commit.txt， 添 加 到 
暂 存 区 中 。 





$ touch detached-commit ,txt 
$ git add detached-commit ,txt 





(2) 看 一 下 状态 ， 会 发 现 其 中 有 “当前 不 处 于 任何 分 支 * 的 字样 ， 
显然 这 是 因为 HEAD 人 处于“ 分离 头 指针 ”模式 。 





$ git status 

# Not currently on any branch. 

# Changes to be committed: 

(use "git reset HEAD <file>..." to unstage) 


new file: detached-commit.txt 


亲 亲 亲 亲 





(3) 执行 提交 。 在 提交 输出 中 也 会 出 现 [detached HEAD...] 的 标 
识 ， 这 也 是 对 用 户 的 警示 。 








$ git commit -m "commit in detached HEAD mode." 
[detached HEAD acc2f69] commit in detached HEAD mode. 
© files changed, 0 insertions(+), © deletions(-) 
create mode 100644 detached-commit.txt 





(4) 此 时 头 指 针 指 癌 了 新 的 提 和 区 。 





$ cat .git/HEAD 
acc2f69cf6f0ae346732382c819080df75bb2191 














(5) 再 查看 一 下 日 志 会 发 现 新 的 提交 是 建立 在 之 前 的 提交 基础 上 
的 。 





git log --graph --pretty=oneline 
acc2f69cf6foae346732382c819080df75bb2191 commit in detached HEAD mode. 
e695606fc5e31b2ff9038a48a3d363f4c21a3d86 which version checked In? 
a0c641e92b10d8bcca1led1bf84ca80340fdefee6 who does commit? 
9e8a761ff9dd343a1380032884f488a2422c495a initialized. 


+ 4* * *{ 





记 下 新 的 提交 ID (acc2f69) ， 然 后 以 master 分 文 名 作为 参数 执行 git 


checkout 命 令 ， 会 切换 到 master 分 支 上 。 


` 切换 到 master 分 支 上 ， 再 没有 之 前 大 段 的 文字 警告 。 





$ git checkout master 
Previous HEAD position was acc2f69,.. commit in detached HEAD mode. 
Switched to branch 'master' 





` 因为 HEAD 头 指针 重新 指向 了 分 支 ， 而 不 是 处 于 “ 断 头 模 
式 ” (分 离 头 指针 模式 ) 。 





$ cat .git/HEAD 
ref: refs/heads/master 





` 切换 之 后 ， 之 前 本 地 建立 的 新 文件 detached-commit.txt 不 见 了 。 





$ 1s 
new-commit.txt welcome.txt 





` 切换 之 后 ， 刚 才 的 提交 日 志 也 不 见 了 。 





git log --graph --pretty=oneline 

4902dc375672fbf52a226e0354100b75d4fe31e3 does master follow this new commit? 
e695606fc5e31b2ff9038a48a3d363f4c21a3d86 which version checked in? 
a0c641e92b10d8bcca1led1bf84ca80340fdefee6 who does commit? 
9e8a761ff9dd343a1380032884f488a2422c495a initialized. 


+ * 4* *{ 











刚才 的 提交 还 存在 于 版 本 库 的 对 象 库 中 吗 ? 看 看 刚才 记 下 的 提交 
ID。 





$ git show acc2f69 
commit acc2f69cf6foae346732382c819080df75bb2191 
Author: Jiang Xin <jiangxin@ossxp.com> 
Date: Sun Dec 5 15:43:24 2010 +0800 
commit in detached HEAD mode. 
diff --git a/detached-commit.txt b/detached-commit .txt 
new file mode 100644 
index 0000000..e69de29 





可 以 看 出 这 个 提交 现在 仍 在 版 本 库 中 。 由 于 这 个 提交 没有 被 任何 分 
文 跟踪 到 ， 因 此 并 不 能 保证 这 个 提交 会 永久 存在 。 实 际 上 当 reflog 中 全 
有 该 提交 的 日 记过 期 后 ， 这 个 提交 随时 都 会 从 版 本 库 中 彻底 清除 。 


8.2 ”挽救 分 离 头 指针 


在 “分 离 头 指针 ?模式 下 进行 的 测试 提交 除了 使 用 提交 ID (acc2f69) 
访问 之 外 ， 不 能 通过 master 分 文 或 其 他 引用 访问 到 。 如 果 这 个 提交 有 是 
master 分 文 所 需要 的 ， 那 么 该 如 何 处 理 呢 ? 如 果 使 用 上 一 章 介绍 的 git 
reset 命 令 ， 的 确 可 以 将 master 分 文 重 置 到 该 测试 提交 “acc2f69”， 但 是 如 
果 那 样 束 会 丢掉 master 分 文 原 先 的 提交 “4902dc3”。 使 用 合并 操作 (git 
merge) 可 以 实现 两 者 的 兼顾 。 


下 面 的 操作 会 将 提交 “acc2f69” 合 并 到 master 分 支 中 来 ， 具 体操 作 过 
程 如 下 。 


(1) 确认 当前 处 于 master 分 文 。 





$ git branch -V 
* master 4902dc3 does master follow this new commit? 





(2) 执行 合并 操作 ， 将 acc2f69 提 交合 并 到 当前 分 支 。 





$ git merge acc2f69 

Merge made by recursive. 

0 files changed, 0 insertions(+), © deletions(-) 
create mode 100644 detached-commit.txt 





(3) 工作 区 中 多 了 一 个 detached-commit.txt 艾 件 。 





$ 1s 
detached-commit.txt new-commit.txt welcome.txt 














(4) 查看 日 志 ， 会 看 到 不 一 样 的 分 文 图 。 即 在 e695606 提 交 开 始 出 
现 了 开发 分 文 ， 而 分 文 在 最 新 的 2b31c19 提 区 发 生 了 合并 。 





$ git log --graph --pretty=oneline 

2b31c199d5b81099d2ecd91619027ab63e8974ef Merge commit 'acc2f69' 

| 

| * acc2f69cf6foae346732382c819080df75bb2191 commit in detached HEAD mode ， 

* | 4902dc375672fbf52a226e0354100b75d4fe31e3 does master follow this new commit? 
I/ 

* e695606fc5e31b2ff9038a48a3d363f4c21a3d86 which version checked in? 

* ag0c641e92b10d8bccaled1bf84ca80340fdefee6 who does commit? 

* 9e8a761ff9dd343a1380032884f488a2422c495a Initialized ， 








(5) 仔细 看 看 最 新 提交 ， 会 看 到 这 个 提交 有 两 个 父 提交 。 这 就 是 
合并 的 奥秘 。 





$ git cat-file -p HEAD 

tree ab676f92936000457b01507e04f4058e855d4df0 

parent 4902dc375672fbf52a226e0354100b75d4fe31e3 

parent acc2f69cf6fOae346732382c819080df75bb2191 

author Jiang Xin <jiangxin@ossxp.com> 1291535485 +0800 
committer Jiang Xin <jiangxin@ossxp.com> 1291535485 +0800 
Merge commit 'acc2f69' 
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8.3 深入 了 解 git checkout 命 令 


检 出 命令 〈git checkout) 是 Git 最 常用 的 命令 之 一 ， 同 时 也 是 一 个 很 


危险 的 命令 ， 因 为 这 条 命令 会 重 写 工 作 区 。 检 出 命令 的 用 法 如 下 : 


























用 法 一 : git checkout [-q] [<commit>] [--] <paths>... 
用 法 二 : git checkout [<branch>] 
用 法 三 : git checkout [-m] [[-b|--orphan] <new_branch>] [<start_point>] 











上 面 列 出 的 第 一 种 用 法 和 第 三 种 用 法 的 区 别 在 于 ， 第 一 种 用 法 在 命 
令 中 包含 路 径 <paths>。 为 了 避免 路 径 和 引用 《或 者 提交 ID) 同名 而 发 
生 冲 突 ， 可 以 在 <paths> 前 用 两 个 连续 的 短线 ( 减 写 ) 作为 分 隔 。 


第 一 种 用 法 的 <commit> 是 可 选项 ， 如 果 省 略 则 相当 于 从 和 暂 存 区 
Gindex) 进行 检 出 。 这 和 上 一 昔 的 重 置 命 令 大 不 相同 : 重 置 的 默认 值 
征 HEAD， 而 检 出 的 默认 值 是 特 存 区 。 因 此 重 置 一 般 用 于 重 置 暂 存 区 
《除非 使 用 --hard 参 数 ， 和 否则 不 重 置 工作 区 ) ， 而 检 出 命令 主要 是 履 盖 
工作 区 《如 果 <commit> 不 省 略 ， 也 会 蔡 换 暂 存 区 中 相应 的 文件 ) 。 








第 一 种 用 法 (包含 了 路 径 <paths> 的 用 法 ) 不 会 改变 HEAD 头 指针 ， 
主要 是 用 于 指定 版 本 的 文件 覆盖 工作 区 中 对 应 的 文件 。 如 果 省 略 
<commit>， 则 会 用 暂 存 区 的 文件 缆 凋 工作 区 的 文件 ， 人 否则 用 指定 提交 中 
的 文件 覆盖 暂 存 区 和 工作 区 中 对 应 的 文件 。 











第 二 种 用 法 《不 使 用 路 径 <paths> 的 用 法 ) 则 会 改变 HEAD 头 指针 。 
之 所 以 后 面 的 参数 写作 <branch>， 和 是 因为 只 有 HEAD 切 换 到 一 个 分 文才 
可 以 对 提交 进行 跟踪 ， 否 则 仍然 会 进入 “分 离 头 指针 ”的 状态 。 在 “分 离 
头 指 针 ? 状 态 下 的 提交 不 能 被 引用 关联 到 ， 从 而 可 能 丢失 。 所 以 用 法 二 
最 主要 的 作用 就 是 切换 到 分 文 。 如 有 宁 省 略 <branch> 则 相当 于 对 工作 区 进 
行 状态 检查 。 








第 三 种 用 法 主要 是 创建 和 切换 到 新 的 分 文 〈<new_branch>) ， 新 的 
分 文 从 <start_point> 指 定 的 提交 开始 创建 。 新 分 文 和 我 们 熟悉 的 master 分 
支 没 有 什么 实质 的 不 同 ， 都 是 在 refs/heads 命 名 空间 下 的 引用 。 关 于 分 支 


和 git checkout 命 令 的 这 个 用 法 会 在 后 面 的 章节 具体 介绍 。 











如 图 8-1 所 示 的 版 本 库 模 型 图 描述 了 git checkout 实 际 完成 的 操作 。 





图 8-1 检 出 命令 与 版 本 库 关系 图 


下 面 通过 一 些 示例 来 具体 看 一 下 检 出 命令 的 不 同 用 法 。 
` 命令 : git checkout branch 


检 出 branch 分 支 。 要 完成 如 图 8-1 中 的 三 个 步 又 ， 更 新 HEAD 以 指 问 
branch 分 支 ， 以 及 用 branch 指 癌 的 树 更 新 暂 存 区 和 工作 区 。 





` 命令 : git checkout 


汇总 显示 工作 区 、 暂 存 区 与 HEAD 的 差异 。 





` 命令 : git checkout HEAD 
同 :Eg 
` 命令 : git checkout--filename 


用 暂 存 区 中 filename 文 件 来 覆盖 工作 区 中 的 名 ename 文 件 。 相 当 于 取 
消 目 上 次 执行 git add filename 以 来 《如果 执行 过 ) 的 本 地 修改 。 














这 个 命令 很 危险 ， 因 为 对 于 本 地 的 修改 会 悄 无 声 妨 地 乾 辣 ， 军 不 留 


再 


` 命令 : git checkout branch--filename 


维持 HEAD 的 指 同 不 变 。 用 branch 所 指 同 的 提交 中 的 flename 蔡 换 暂 
存 区 和 工作 区 中 相应 的 文件 。 注 意 会 将 暂 存 区 和 工作 区 中 的 filename 文 


件 直 接 黎 普 。 


` 命令: git checkout--. 或 写作 git checkout. 





注意 ”git checkout 命 令 后 的 参数 为 一 个 点 (“.”) 。 这 条 命令 最 危 
险 ! 会 取消 所 有 本 地 的 修改 〈 相 对 于 和 暂 存 区 ) 。 相 当 于 用 和 暂 存 区 的 所 有 
文件 直接 图 盖 本 地 文件 ， 不 给 用 户 任何 确认 的 机 会 ! 


第 9 章 ”恢复 进度 


在 之 前 “第 5 草 Git 暂 存 区 ”一 章 的 结尾 ， 曾 经 以 终结 者 〈The 
Terminator) 的 口吻 说 过 : “我 会 再 回来 的 ”， 会 继续 对 和 暂 存 区 的 探索 。 
经 过 了 前 面 三 间 对 Git 对 象 、 重 置 命 令 和 检 出 命令 的 探索 ， 现 在 已 经 拥 
有 了 足够 多 的 武器 ， 是 时 候 “ 回 归 ? 了 。 











本 章 “ 回 归 ” 之 后 ， 有 了 前 面 几 间 的 基础 ， 再 看 Git 状 态 输出 中 关于 
git reset 或 git checkout 的 指示 ， 大 家 就 会 觉得 很 亲切 、 易 如 反 掌 了 。 本 章 
还 会 重点 介绍 “回归 ”使 用 的 git stash 命 令 。 











9.1 ”继续 暂 存 区 未 完成 的 实践 


经 过 了 前 面 的 实践 ， 现 在 DEMO 版 本 库 应 该 处 于 master 分 文 上 ， 看 





$ cd /path/to/my/workspace/demo 
$ git status -sb # Git 1.7.2 及 以 上 版 本 才 支 持 -b 参数 哦 
## master 
$ git log --graph --pretty=oneline --stat 
风 2b31c199d5b81099d2ecd91619027ab63e8974ef Merge commit 'acc2f69' 
| 
| * acc2f69cf6foae346732382c819080df75bb2191 commit in detached HEAD mode ， 
| | 9 files changed, © insertions(+)， 0 deletions(-) 
* | 4902dc375672fbf52a226e0354100b75d4fe31e3 does master follow this new commit? 
I/ 
| 9 files changed, 0 insertions(+), © deletions(-) 
* e695606fc5e31b2ff9038a48a3d363f4c21a3d86 which version checked in? 
| welcome.txt | 1 + 
| 1 files changed, 1 insertions(+), © deletions(-) 
* agc641e92b10d8bccaled1bf84ca80340fdefee6 who does commit? 
* ge8a761ff9dd343a1380032884f488a2422c495a initialized ， 
welcome.txt | 1 + 
1 files changed, 1 insertions(+), 0 deletions(-) 








还 记得 在 之 前 “第 5 章 Git 暂 存 区 ”一 章 的 结尾 是 如 何 保存 进度 的 吗 ? 
翻 回去 看 一 下 ， 用 的 是 git stash 命 令 。 这 个 命令 用 于 保存 当前 进度 ， 也 
是 恢复 进度 要 用 的 命令 。 


查看 保存 的 进度 用 命令 git stash list。 





$ git stash list 
stash@{0}: WIP on master: e695606 which version checked in? 








现在 就 来 恢复 进度 。 使 用 git stash pop 从 最 近 保 存 的 进度 进行 恢复 。 





$ git stash pop 

# On branch master 

# Changes to be committed: 

# (use "git reset HEAD <file>..." to unstage) 

# 

# new file: a/b/c/hello.txt 

## 

# Changes not staged for commit: 

# (use "git add <file>..." to update what will be committed) 
# (use "git checkout -- <file>,..." to discard changes in working directory) 
# 

# modified: welcome.txt 

# 

D 


ropped refs/stash@{0} (clbd56e2565abd64a0d63450fe42aba23b673cf3 ) 





先 不 要 管 git stash pop 命 令 的 输出 ， 后 面 会 专题 介绍 git stash 命 令 。 
通过 查看 工作 区 的 状态 ， 可 以 发 现 进度 已 经 找 回 了 (状态 与 进度 保存 前 
稍 有 不 同 ) 。 








$ git status 

# On branch master 

# Changes to be committed: 

# (use "git reset HEAD <file>..." to unstage) 

# 

# new file: a/b/c/hello.txt 

## 

# Changes not staged for commit: 

# (use "git add <file>..." to update what will be committed) 
# (use "git checkout -- <file>,..." to discard changes in working directory) 
# 

# modified: welcome.txt 

# 











此 时 再 看 Git 的 状态 输出 ， 是 否 别有一番 感觉 呢 ? 有 了 前 面 三 革 的 
基础 ， 现 在 可 以 游 胃 有 余地 应 对 各 种 情况 了 。 


(1) 以 当前 暂 存 区 的 状态 进行 提交 ， 即 只 提交 a/b/c/hello.txt， 不 提 


交 welcome.txt。 





$ git commit -m "add new file: a/b/c/hello.txt, but leave welcome .txt alone." 
[master 6610d05] add new file: a/b/c/hello.txt, but leave welcome.txt alone. 
1 files changed, 2 insertions(+), 0 deletions(-) 
create mode 100644 a/b/c/hello.txt 





查看 提交 后 的 状态 : 





$ git status -s 
M welcome.txt 





(2) 反悔 了 ， 回 到 之 前 的 状态 。 


用 重 置 命令 放弃 最 新 的 提交 





$ git reset --soft HEAD^ 





查看 最 新 的 提交 日 志 ， 可 以 看 到 前 面 的 提交 被 抛弃 了 。 





$ git 1og -1 --pretty=oneline 
2b31c199d5b81099d2ecd91619027ab63e8974ef Merge commit 'acc2f69 





工作 区 和 和 暂 存 区 的 状态 也 都 维持 在 原来 的 状态 。 








$ git status -s 
A a/b/c/hello.txt 
M welcome.txt 





(3) 想 将 welcome.txt 提 交 。 





$ git add welcome.txt 
$ git status -s 

A a/b/c/hello.txt 

M welcome.txt 


(4) 想 将 a/b/c/hello.txt 撤 出 暂 存 区 。 


也 是 用 重 置 命 令 。 





$ git reset HEAD a/b/c 
$ git status -s 

M welcome.txt 

?7 a/ 





(5) 想 将 剩 下 的 文件 (welcome.txt) 从 暂 存 区 撤 出 ， 就 是 说 不 想 
提交 任何 东西 了 。 








还 是 使 用 重 置 命令 ， 甚 至 可 以 不 使 用 任何 参数 。 





$ git reset 
Unstaged changes after reset : 
M welcome.txt 





(6) 想 将 本 地 工作 区 所 有 的 修改 清除 。 即 清除 welcome.txt 的 改 
动 ， 删 除 添加 的 目录 a 及 下 面 的 子 日 录 和 文件 。 





清除 welcome.txt 的 改动 用 检 出 命令 。 


实际 对 于 此 例 执行 git checkout. 也 可 以 。 





$ git checkout -- welcome.txt 





工作 区 显示 还 有 一 个 多 余 的 目录 a。 





$ git status 

# On branch master 

# Untracked files: 

# (use "git add <file>..." to include in what will be committed) 
# 
# a/ 





删除 本 地 多 余 的 目录 和 文件 ， 可 以 使 用 git clean 命 令 。 先 来 测试 运 
行 以 便 看 看 哪些 文件 和 目录 会 被 删除 ， 以 免 造 成 误 删 。 





$ git clean -nd 
Would remove a/ 





真正 开始 强制 删除 多 余 的 目录 和 文件 。 





$ git clean -fd 
Removing a/ 





整个 世界 清净 了 。 





$ git status -s 





9.2 ”使 用 git stash 





命令 git stash 可 以 用 于 保存 和 恢复 工作 进度 ， 掌 握 这 个 命令 对 于 日 
常 的 工作 会 有 很 大 的 帮助 。 关 于 这 个 命令 的 最 主要 的 用 法 实际 上 通过 前 
面 的 演示 已 经 了 解 了 。 








` 命令 : git stash 


保存 当前 的 工作 进度 。 会 分 别 对 暂 存 区 和 工作 区 的 状态 进行 保存 。 





` 命令 : git stash list 








显示 进度 列表 。 此 命令 显然 暗示 了 git stash 可 以 多 次 保存 工作 进 
度 ， 并 且 在 恢复 的 时 候 进行 选择 。 





` 命令 : git stash pop[--index][<stash>] 


如 采 不 使 用 任何 参数 ， 会 恢复 最 新 保存 的 工作 进度 ， 并 将 恢复 的 工 
作 进 度 从 存储 的 工作 进度 列表 中 清除 。 





如 果 提 供 <stash> 参 数 (来 自 于 git stash list 显 示 的 列表 ) ， 则 从 该 
<stash> 中 恢复 。 恢 复 完毕 也 将 从 进度 列表 中 删除 <stash>。 








选项 --index 除 了 恢复 工作 区 的 文件 外 ， 还 尝试 恢复 暂 存 区 。 这 也 就 


是 为 什么 在 本 章 一 开始 恢复 进度 的 时 候 显示 的 状态 和 保存 进度 前 的 略 有 
不 同 。 


命令 : ait stash[save[--patch|[-k|--[no-]keep-index|[-q | --quied] 
[<message>]] 


这 条 命令 实际 上 是 第 一 条 git stash 命 令 的 完整 版 。 即 如 果 需 要 在 保 


存 工作 进度 的 时 候 使 用 指定 的 说 明 ， 必 须 使 用 如 下 格式 : 





git stash save "message..." 





` 使 用 参数 --patch 会 显示 工作 区 和 HEAD 的 差异 ， 通 过 对 差异 文 
件 的 编辑 决定 在 进度 中 最 终 要 保存 的 工作 区 的 内 容 ， 通 过 编辑 差异 文件 
可 以 在 进度 中 排除 无 关内 


` 使 用 -或 --keep-index 参 数 ， 在 保存 进度 后 不 会 将 暂 存 区 重 置 。 
默认 会 将 暂 存 区 和 工作 区 强制 重 置 。 


命令: git stash apply[--index][<stash>] 


除了 不 删除 恢复 的 进度 之 外 ， 其 余 和 git stash pop 命 令 一 样 。 


从 


` 命令 : git stash drop[<stash>] 


删除 一 个 存储 的 进度 。 默 认 删 除 最 新 的 进度 。 


命令: git stash clear 


删除 所 有 存储 的 进度 。 


` 命令 : git stash branch<branchname><stash> 


基于 进度 创建 分 文 。 对 了 ， 还 没有 讲 到 分 文 呢 。 


9.3 ”探秘 git stash 


了 解 一 下 git stash 的 机 理会 有 几 个 好 处 : 当 保 存 了 多 个 进度 的 时 候 
知道 从 哪个 进度 恢复 ; 综合 运用 前 面 介 绍 的 Git 知 识 点 :了解 Git 的 源 
码 ，Git 将 不 再 神秘 。 


在 执行 git stash 命 令 时 ，Git 实 际 调 用 了 一 个 脚本 文件 实现 相关 的 功 
能 ， 这 个 脚本 的 文件 名 就 是 git-stash。 看 看 git-stash 安 装 在 哪里 了 。 





$ git --exec-path 
/usr/lib/git-core 





如 果 碍 看 一 下 这 个 目录 ， 您 会 震惊 的 。 





$ ls /usr/lib/git-core/ 


git git-help git-reflog 

git-add git-http-backend git-relink 

git-add--interactive git-http-fetch git-remote 

git-am git-http-push git-remote-ftp 

git-annotate git-imap-send git-remote-ftps 

git-apply git-index-pack git-remote-http 
省 略 49 余 行 








实际 上 在 1.5.4 之 前 的 版 本 中 ，Git 会 将 这 样 的 一 百 多 个 以 git-<cmd> 
格式 命名 的 程序 安装 到 可 执行 路 径 中 ， 而 这 样 做 的 唯一 好 处 就 是 不 用 借 
助 任 何 扩展 机 制 就 可 以 实现 命令 行 补 齐 : 即 键入 git- 后 ， 连 续 两 次 键入 
<Tab> 键 ， 束 可 以 把 这 一 百 多 个 命令 显示 出 来 。 这 种 方式 随 着 Git 子 命令 





的 增加 显得 越 来 越 混乱 ， 因 此 从 1.5.4 版 本 开始 ， 不 再 提供 git-<cmd> 格 
式 的 命令 ， 而 是 用 唯一 的 git 命 令 。 而 之 前 的 名 为 git-<cmd> 的 子 命 令 则 
保存 在 非 可 执行 目录 下 ， 由 Git 负 责 加 载 。 





在 后 面 的 章节 中 偶尔 会 看 到 形 如 git-<cmd> 字 样 的 名 称 ， 以 及 同时 
存在 的 git<cmd> 命 令 。 可 以 这 样 理解 : git-<cmd> 作 为 软件 本 身 的 名 称 ， 


而 其 命令 行为 git<cmd>。 





最 初 很 多 Git 命 令 都 是 用 Shell 或 Perl 脚 本 语言 开发 的 ， 在 Git 的 发 展 
中 一 些 对 运行 效率 要 求 高 的 命令 用 C 语 言 改 写 。 而 git-stash (人 至少 在 Git 
1.7.4 版 本 ) 还 是 使 用 Shell 脚 本 开发 的 ， 研 究 它 比 研究 用 C 写 的 命令 要 简 





$ file /usr/lib/git-core/git-stash 
/usr/lib/git-core/git-stash: POSIX shell Script text executable 





解析 git-stash 脚 本 会 比较 枯燥 ， 还 是 通过 运行 一 些 示 例 来 理解 更 好 
一 些 


一 一: 





当前 的 进度 保存 列表 是 空 的 。 





$ git stash list 





下 面 在 工作 区 中 做 一 些 改动 。 





$ echo Bye-Bye. >> welcome.txt 


$ echo hello. > hack-1.txt 
$ git add hack-1.txt 
$ git status -s 
A hack-1.txt 
M welcome.txt 





可 见 暂 存 区 中 己 经 添加 了 新 增 的 hack-1.txt， 修 改过 的 welcome.txt 并 
未 添加 到 和 暂 存 区 。 执 行 git stash 保 存 一 下 工作 进度 。 





$ git stash save "hack-1: hacked welcome.txt, newfile hack-1.txt" 
Saved working directory and index state On master: hack-1: hacked welcome.txt, newf 
HEAD is now at 2b31c19 Merge commit 'acc2f69' 





工作 区 恢复 了 修改 前 的 原貌 (实际 上 用 了 git reset--hard HEAD 命 
令 ) ， 文 件 welcome.txt 的 修改 不 见 了 ， 文 件 hack-1.txt 整 个 都 不 见 了 。 





$ git status -s 
$ 1s 
detached-commit.txt new-commit.txt welcome.txt 





再 做 一 个 修改 ， 并 答 试 保存 进度 。 





$ echo fix. > hack-2.txt 
$ git stash 
No local changes to save 





进度 保存 失败 ! 可 见 本 地 没有 被 版 本 控制 系统 跟 踊 的 文件 并 不 能 保 
存 进度 。 因 此 本 地 新 文件 需要 先 执 行 添 加 操作 ， 然 后 再 执行 git stash 命 


令 。 





$ git add hack-2.txt 

$ git stash 

Saved working directory and index state WIP on master: 2b31c19 Merge commit 'acc2f6¢ 
HEAD is now at 2b31c19 Merge commit 'acc2f69' 





不 用 看 束 知 道 工 作 区 再 次 恢复 原状 。 如 果 这 时 执行 git stash list 会 看 
到 有 两 次 进度 保存 。 





$ git stash list 
stash@{0}: WIP on master: 2b31c19 Merge commit 'acc2f69' 
stash@{1}: On master: hack-1: hacked welcome.txt, newfile hack-1.txt 





从 上 面 的 输出 中 可 以 得 出 两 个 结论 


* 在 用 git stash 命 令 保 存 进度 时 ， 如 果 提 供 说 明 则 更 容易 通过 进度 列 
表 找 到 保存 的 进度 


. 每 个 进度 的 标识 都 是 stash(@{<n>} 格 式 ， 像 极 了 前 面 介绍 的 reflog 
的 格式 。 


实际 上 ，git stash 就 是 用 前 面 介 绍 的 引用 和 引用 变更 日 志 (reflog) 
来 实现 的 。 





$ ls - .git/refs/stash .git/logs/refs/stash 
-rw-r--r-- 1 jiangxin jiangxin 364 Dec 6 16:11 .git/logs/refs/stash 
-rw-r--r-- 1 jiangxin jiangxin 41 Dec 6 16:11 .git/refs/stash 








那么 在 “第 7 章 Git 重 置 ?一 章 中 学 习 的 reflog 可 以 派 上 用 场 了 。 





$ git reflog show refs/stash 
escOcdc refs/stash@{0}: WIP on master: 2b31c19 Merge commit 'acc2f69' 
6cec9db refs/stash@{1}: On master: hack-1: hacked welcome.txt, newfile hack-1.txt 





对 照 git reflog 的 结果 和 前 面 git stash list 的 结果 ， 可 以 肯定 用 git stash 
保存 进度 ， 实 际 上 会 将 进度 保存 在 引用 refs/stash 所 指 问 的 提交 中 。 多 次 
的 进度 保存 ， 实 际 上 相当 于 引用 refs/stash 一 次 又 一 次 的 变化 ， 而 
refs/stash 引 用 的 变化 由 reflog 〈( 即 .git/logs/refs/stash〉 所 记录 下 来 。 这 个 
实现 是 多 么 简单 而 巧妙 啊 。 








一 个 新 的 疑问 又 出 现 了 ， 如 何在 引用 refs/stash 中 同时 保存 暂 存 区 的 
进度 和 工作 区 中 的 进度 呢 ? 查 看 一 下 引用 refs/stash 的 提交 历史 能 够 看 出 
端倪 。 





$ git log --graph --pretty=raw refs/stash -2 

commit e5cocdc2dedc3e50e6b72a683d928e19a1d9de48 

tree 780c22449b7ff67e2820e09a6332c360ddc80578 

parent 2b31c199d5b81099d2ecd91619027ab63e8974ef 

parent c5edbdcc9oaddb06577ff60f644acd1542369194 

author Jiang Xin <jiangxin@ossxp.com> 1291623066 +0800 
committer Jiang Xin <jiangxin@ossxp.com> 1291623066 +0800 


WIP on master: 2b31c19 Merge commit "acc2f69 


a 


* 
| 
| 

| 

| 

| 

| 

| 

| 

| commit c5edbdcc90addb06577ff60f644acd1542369194 

|/ tree 780c22449b7ff67e2820e09a6332c360ddc80578 

| parent 2b31c199d5b81099d2ecd91619027ab63e8974ef 

| author Jiang Xin <jiangxin@ossxp.com> 1291623066 +0800 

| committer Jiang Xin <jiangxin@ossxp.com> 1291623066 +0800 
| 

| 


index on master: 2b31c19 Merge commit 'acc2f69' 








从 提交 历史 中 可 以 看 到 进度 保存 的 最 新 提交 是 一 个 合并 提交 。 最 新 
的 提交 说 明 中 有 WIP 字 样 (是 Work In Progess 的 简称 ) ， 代 表 了 工作 区 
进度 。 而 最 新 提交 的 第 二 个 父 提交 提交 历史 中 显示 为 第 二 个 提交 ) 有 


index on master 字 样 ， 说 明 这 个 提交 代表 着 暂 存 区 的 进度 。 





但 是 提交 历史 中 的 两 个 提交 都 指向 了 同一 个 树 
这 是 因为 最 后 一 次 做 进度 保存 时 工作 区 相对 暂 存 区 没有 改变 ， 这 使 得 工 
作 区 和 和 暂 存 区 在 引用 refs/stash 中 的 存储 变 得 有 些 扑朔迷离 。 别 忘 
次 进度 保存 工作 区 、 暂 存 区 和 版 本 库 都 是 不 同 的 ， 可 以 用 于 验证 关于 
refs/stash 实 现 机 制 的 判断 。 


tree 780C224...， 














一 次 进度 保存 可 以 使 用 reflog 中 的 语法 ， 即 用 refs/stash@{1} 来 访 
问 ， 也 可 以 用 简称 stash@{1}。 下 面 就 来 研究 一 下 第 一 次 的 进度 保存 。 








$ git log --graph --pretty=raw stash@{1} -3 
commit 6cec9db44af38d01abe7b5025a5190c56fdgocf49 
\ tree 7250f186c6aa3e2d1456d7fa915e529601f21d71 
parent 2b31c199d5b81099d2ecd91619027ab63e8974ef 
parent 4560d76c19112868a6a5692bf9379de09c0452b7 
author Jiang Xin <jiangxin@ossxp.com> 1291622767 +0800 
committer Jiang Xin <jiangxin@ossxp.com> 1291622767 +0800 


On master: hack-1: hacked welcome.txt, newfile hack-1.txt 


EE 


大 
| 
| 
| 
| 
| 
| 
| 
| 
| commit 4560d76c19112868a6a5692bf9379de09c0452b7 

|/ tree 5d4dd328187e119448c9171f99cf2e507e91a6c6 

| parent 2b31c199d5b81099d2ecd91619027ab63e8974ef 

| author Jiang Xin <jiangxin@ossxp.com> 1291622767 +0800 

| committer Jiang Xin <jiangxin@ossxp.com> 1291622767 +0800 
| 

| 

| 

* 

| 

| 

| 

| 

| 

| 

| 


index on master: 2b31c19 Merge commit 'acc2f69' 


commit 2b31c199d5b81099d2ecd91619027ab63e8974ef 
\ tree ab676f92936000457b01507e04f4058e855d4df0 
parent 4902dc375672fbf52a226e0354100b75d4fe31e3 
parent acc2f69cf6fOae346732382c819080df75bb2191 
author Jiang Xin <jiangxin@ossxp.com> 1291535485 +0800 
committer Jiang Xin <jiangxin@ossxp.com> 1291535485 +0800 


Merge commit 'acc2f69' 








果然 上 面 显 示 的 三 个 提交 对 应 的 三 棵 树 各 不 相同 。 查 看 一 下 差 
用 “ 原 基 线 ” 代 表 进 度 保存 时 版 本 库 的 状态 ， 即 提交 2b31c199; 用 “ 原 暂 
存 区 ”代表 进度 保存 时 暂 存 区 的 状态 ， 即 提交 4560d76; 用 “ 原 工作 区 ” 代 





表 进 度 保存 时 工作 区 的 状态 ， 即 提交 6cec9db。 


` 原 基 线 和 原 暂 存 区 的 差异 比较 。 





$ git diff stash@{1}^2^ stash@{1}^2 
diff --git a/hack-1.txt b/hack-1.txt 
new file mode 100644 

index 0000000. .25735f5 

--- /dev/null 

+++ b/hack-1.txt 

@@ -0, 0 +1 @@ 

+hello. 





` 原 暂 存 区 和 原 工作 区 的 差异 比较 。 





$ git diff stash@{1}^2 stash@{1} 
diff --git a/welcome.txt b/welcome.txt 
index fd3c069..51dbfd2 100644 
--- a/welcome.txt 
+++ b/welcome.txt 
QQ -1, 2 +1, 3 @@ 
Hello. 
Nice to meet you. 
+Bye-Bye. 





. 原 基 线 和 原 工作 区 的 差异 比较 。 





$ git diff stash@{1}^1 stash@{1} 
diff --git a/hack-1.txt b/hack-1.txt 
new file mode 100644 
index 0000000. .25735f5 
--- /dev/null 
+++ b/hack-1.txt 
@@ -0, 9 +1 @@ 
+hello. 
diff --git a/welcome.txt b/welcome.txt 
index fd3c069, .51dbfd2 100644 
--- a/welcome.txt 
+++ b/welcome.txt 
QQ -1, 2 +1, 3 @@ 
Hello. 
Nice to meet you. 
+Bye-Bye. 


二 一 


用 stash@O{1} 来 恢复 进度 。 





git stash apply stash@{1} 
on branch master 
Changes to be committed: 
(use "git reset HEAD <file>..." to unstage) 


new file: hack-1.txt 
Changes not staged for commit: 
(use "git add <file>..." to update what will be committed) 


(use "git checkout -- <file>,..." to discard changes in working directory) 


modified: welcome.txt 


亲 亲 闪闪 亲 亲 亲 亲 亲 亲 亲 亲 人 切 








显示 进度 列表 ， 然 后 删除 进度 列表 。 





$ git stash list 

stash@{0}: WIP on master: 2b31c19 Merge commit 'acc2f69' 

stash@{1}: On master: hack-1: hacked welcome.txt, newfile hack-1.txt 
$ git stash clear 





删除 进度 列表 之 后 ， 会 发 现 stash 相 关 的 引用 和 reflog 都 不 见 了 。 





$ ls - .git/refs/stash .git/logs/refs/stash 
JS: cannot access .git/refs/stash: No such file or directory 
JS: cannot access .git/logs/refs/stash: No such file or directory 





通过 上 面 的 这 些 分 析 ， 有 一 定 Shell 编 程 基础 的 读者 就 可 以 尝试 研究 
git-stash 的 代码 了 ， 在 研究 过 程 中 你 可 能 会 有 新 的 发 现 。 


第 10 章 ”Git 基 本 操作 


之 前 的 实践 选取 的 示例 都 非常 简单 ， 基 本 上 都 是 增加 和 修改 文本 文 
件 ， 而 现实 情况 要 复杂 得 多 ， 需 要 应 对 各 种 情况 : 文件 删除 、 文 件 复 
制 、 文 件 移动 、 目 录 的 组 织 、 二 进 制 文件 、 误 删 文 件 的 恢复 ， 等 等 。 














本 章 要 用 一 个 更 为 真实 的 例子 : 通过 对 Hello World 程 序 源 代码 的 版 
本 控制 ， 来 介绍 工作 区 中 其 他 的 一 些 常 用 操作 。 首 先 我 们 会 删除 之 前 历 
次 实践 在 版 本 库 中 留 下 的 “垃圾 ”数据 ， 然 后 再 在 其 中 创建 一 些 真 实 的 代 
码 ， 并 对 其 进行 版 本 控制 。 


10.1 ”人 先 来 合 个 有 影 


马上 就 要 和 之 前 实践 遗留 的 数据 告别 了 ， 告 别 之 前 是 不 是 要 留 个 影 
呢 ? 在 Git 里 , “留影 ?用 的 命令 叫 作 tag， 更 加 专业 的 术语 叫 作 “里 程 
碑 ”( 打 tag， 或 打 标 签 ) 。 “留影 "操作 如 下 : 





$ cd /path/to/my/workspace/demo 
$ git tag -m "Say bye-bye to all previous practice." old practice 





本 章 还 不 打算 详细 介绍 里 程 碑 的 奥秘 ， 只 要 知道 里 程 碑 无 非 也 是 一 
个 引用 ， 通 过 记录 提交 ID (或 者 创建 Tag 对 象 ) 来 为 当前 版 本 库 的 状态 


进行 “留影 ”。 





$ ls .git/refs/tags/old_practice 
.git/refs/tags/old_practice 

$ git rev-parse refs/tags/old practice 
41bd4e2ccegof8baa9bb4cdda62927b408c846cd6 





留 过 影 之 后 ， 可 以 执行 git describe 命 令 将 最 新 提交 显示 为 一 个 易 记 
的 名 称 。 显 示 的 时 候 会 选取 离 该 提交 最 近 的 里 程 碑 作为 “基础 版 本 号 ”， 
后 面 附加 标识 距离 “基础 版 本 ”的 数字 ， 以 及 该 提交 的 SHA1 哈 希 值 缩 
写 。 因 为 最 新 的 提交 上 恰好 被 打 了 一 个 “里 程 碑 ”， 所 以 直接 显示 “里 程 
碑 ? 的 名 称 。 这 个 技术 会 在 后 面 的 示例 代码 中 多 次 用 到 。 














$ git describe 
old_practice 





10.2 ”删除 文件 








看 看 版 本 库 当 前 的 状态 ， 暂 存 区 和 工作 区 都 包含 修改 。 








$ git status -s 
A hack-1.txt 
M welcome.txt 





在 这 个 暂 存 区 和 工作 区 都 包含 文件 修改 的 情况 下 ， 使 用 删除 命令 更 
具有 挑战 性 。 删 除 命令 有 多 种 使 用 方法 ， 有 的 方法 很 巧妙 ， 而 有 的 方法 
则 需要 更 多 的 输入 。 为 了 分 别 介绍 不 同 的 删除 方法 ， 还 要 使 用 上 一 章 介 
绍 的 进度 保存 〈git stash) 命令 。 





“ 保存 进度 。 





$ git stash 
Saved working directory and index state WIP on master: 2b31c19 Merge commit 'acc2f6¢ 
HEAD is now at 2b31c19 Merge commit 'acc2f69' 





再 恢复 进度 。 注 意 不 要 使 用 git stash pop， 而 是 使 用 git stash apply， 
因为 这 个 保存 的 进度 要 被 多 次 用 到 。 





$ git stash apply 

# On branch master 

# Changes to be committed: 

(use "git reset HEAD <file>..." to unstage) 


new file: hack-1.txt 
Changed but not updated: 


(use "git add <file>..." to update what will be committed) 
(use "git checkout -- <file>,..." to discard changes in working directory) 


亲 半 亲 亲 半 亲 六 


modified: welcome.txt 


亲 亲 站 


10.2.1 本 地 删除 不 是 真 的 删除 


当前 工作 区 的 文件 有 : 


$ 1s 
detached-commit.txt 
hack-1.txt 
nNew-commit.txt 
welcome.txt 





直接 在 工作 区 删除 这 些 文件 ， 会 如 何 呢 ? 


通过 下 面 的 命令 ， 可 以 看 到 在 暂 存 区 版 本 库 ) 中 的 文件 仍然 存 
在 ， 并 未 删除 。 


$ git ls-files 
detached-commit.txt 
hack-1.txt 
nNew-commit .txt 
welcome.txt 


从 文件 的 状态 来 看 ， 文 件 只 是 在 本 地 进行 了 删除 ， 尚 未 添加 到 暂 存 
区 提交 任务 ) 中 。 也 就 是 说 ; 直接 在 工作 区 删除 ， 对 暂 存 区 和 版 本 库 
没有 任何 影响 。 





$ git status 


# On branch master 
Changes to be committed: 
(use "git reset HEAD <file>..." to unstage) 


new file: hack-1.txt 


Changed but not updated: 
(use "git add/rm <file>..." to update what will be committed) 
(use "git checkout -- <file>,..." to discard changes in working directory) 


deleted: detached-commit.txt 
deleted: hack-1.txt 

deleted: nNew-commit.txt 
deleted: welcome.txt 


亲 亲 亲 亲 亲 亲 亲 亲 亲 亲 亲 亲 亲 条 





从 Git 状 态 输出 中 可 以 看 出 ， 本 地 删除 如 果 要 反映 在 暂 存 区 中 应 该 
用 git rm 命令 ， 对 不 想 删 除 的 文件 执行 git checkout--<file>， 可 以 让 文件 
在 工作 区 重 现 。 


10.2.2 ”执行 git rm 命令 删除 文件 


好 吧 ， 按 照 上 面 状 态 输出 的 内 容 ， 将 所 有 的 文本 文件 删除 。 执 行 下 
面 的 命令 





$ git rm detached-commit ,txt hack-1.txt new-commit.txt welcome.txt 
rm 'detached-commit.txt" 

rm 'hack-1.txt' 

rm 'new-commit.txt' 

rm 'welcome.txt' 





再 看 一 看 状态 : 





git status 
on branch master 
Changes to be committed: 
(use "git reset HEAD <file>..." to unstage) 


亲 亲 半 亲 亲人 妇 


deleted: detached-commit.txt 


deleted: new-commit.txt 
deleted: welcome.txt 


亲 亲 六 





删除 动作 加 入 了 和 暂 存 区 。 这 时 执行 提交 动作 ， 束 从 真正 意义 上 执行 
了 文件 删除 。 





$ git commit -m "delete trash files. (using: git rm)" 
[master 483493a] delete trash files. (using: git rm) 
1 files changed, © insertions(+), 2 deletions(-) 
delete mode 100644 detached-commit.txt 
delete mode 100644 new-commit.txt 
delete mode 100644 welcome.txt 








不 过 不 要 担心 ， 文 件 只 是 在 版 本 库 的 最 新 提交 中 被 删除 了 ， 在 历史 
提交 中 尚 在 。 可 以 通过 下 面 的 命令 但 看 历史 版 本 的 文件 列表 。 





$ git ls-files --with-tree=HEADA^ 
detached-commit.txt 

New-commit .txt 

welcome.txt 





也 可 以 但 看 在 历史 版 本 中 尚 在 的 删除 文件 的 内 容 。 





$ git cat-file -p HEAD^:welcome.txt 
Hello. 
Nice to meet you. 





10.2.3 ”命令 git add-u 快 速 标 记 删 除 


在 前 面 执行 git rm 命令 时 ， 写 下 了 所 有 要 删除 的 文件 名 ， 好 长 的 命 
令 啊 ! 能 不 能 简化 些 ? 实际 上 git add 就 可 以 ， 即 使 用 -u 参 数 调 用 git add 


命令 ， 合 义 是 将 本 地 有 改动 〈 包 括 修改 和 删除 ) 的 文件 标记 到 暂 存 区 。 
为 了 重 现 刚 才 的 场景 ， 先 使 用 重 置 命令 抛 痉 最 新 的 提交 ， 再 使 用 进度 恢 
复 到 之 前 的 状态 ， 具 体操 作 过 程 如 下 。 


(1) 丢弃 之 前 测试 删除 的 试验 性 提交 。 


$ git reset --hard HEAD^ 
HEAD is now at 2b31c19 Merge commit 'acc2f69' 


(2) 恢复 保存 的 进度 。 (参数 -q 使 得 命令 进入 安静 模式 。) 


$ git stash apply -q 


(3) 然后 删除 本 地 文件 ， 状 态 显 示 出 依然 只 是 在 本 地 删除 了 文 
件 ， 暂 存 区 中 的 文件 仍 在 。 





$ rm *.txt 
$ git status -s 

D detached-commit.txt 
AD hack-1.txt 

D new-commit.txt 

D welcome.txt 





(4) 执行 git add-u 命 令 可 以 将 (被 版 本 库 退 踪 的 ) 本 地 文件 的 变更 
(人 修改、 删除》 全 部 记录 到 暂 存 区 中 。 


$ git add -u 


(5) 查看 状态 ， 可 以 看 到 工作 区 删除 的 文件 全 部 被 标记 为 下 次 提 


交 时 删除 。 





$ git Status -S 

D detached-commit.txt 
D new-commit.txt 

D welcome.txt 





(6) 执行 提交 ， 删 除 文件 。 





$ git commit -m "delete trash files,., (using: git add -u)" 
[master 7161977] delete trash files. (using: git add -u) 
1 files changed, © insertions(+), 2 deletions(-) 
delete mode 100644 detached-commit.txt 
delete mode 100644 new-commit.txt 
delete mode 100644 welcome.txt 


to—raeen | 


10.3 ”恢复 删除 的 文件 


经 过 了 上 面 的 文件 删除 ， 工 作 区 已 经 没有 文件 了 。 为 了 说 明文 件 移 
动 ， 现 在 恢复 一 个 删除 的 文件 。 前 面 已 经 说 过 执行 了 文件 删除 并 提交 ， 
只 是 在 最 新 的 提交 中 删除 了 文件 ， 历 史 提 交 中 文件 仍然 保留 ， 可 以 从 历 
史 提 交 中 提取 文件 。 执 行 下 面 的 命令 可 以 从 历史 《前 一 次 提交 ) 中 恢复 


welcome.txt 文 件 。 


$ git cat-file -p HEAD~1:welcome.txt > welcome.txt 


也 可 以 使 用 git show 命 令 取 代 git cat-file-p 命 令 ， 效 果 相 同 。 





$ git Show HEAD~1:welcome.txt > welcome.txt 


使 用 git checkout 命 令 则 最 为 简洁 实用 。 





$ git checkout HEAD~1 -- welcome.txt 





上 面 的 命令 中 出 现 的 HEAD~1 即 相当 于 HEAD^ 都 指 的 是 HEAD 的 上 
一 次 提交 。 执 行 git add-A 命 令 会 将 工作 区 中 的 所 有 改动 及 新 增 文件 添加 
到 暂 存 区 ， 这 也 是 一 个 常用 的 技巧 。 执 行 下 面 的 命令 后 ， 将 恢复 过 来 的 
welcome.txt 文 件 添加 回 暂 存 区 。 





$ git add -A 


$ git status -s 
A welcome.txt 


执行 提交 操作 ， 文 件 welcome.txt 又 回来 了 。 


$ git commit -m "restore file: welcome.txt" 
[master 63992f0] restore file: welcome.txt 
1 files changed, 2 insertions(+), 0 deletions(-) 
create mode 100644 welcome.txt 








通过 再 次 添加 的 方式 恢复 被 删除 的 文件 是 最 上 自然 的 恢复 方法 。 其 他 
版 本 控制 系统 如 CVS 也 采用 同样 的 方法 恢复 删除 的 文件 ， 但 是 有 的 版 本 
控制 系统 (如 Subversion〉 如 末 这 样 操作 会 有 严重 的 副作用 一 一 文件 变 
更 历史 被 人 为 地 制 裂 ， 而 且 还 会 造成 服务 器 存储 空间 的 浪费 。Git 通 过 
添加 方式 反 删除 文件 没有 副作用 ， 这 是 因为 在 Git 的 版 本 库 中 相同 内 容 
的 文件 保存 在 一 个 blob 对 象 中 ， 即 便 是 内 容 不 同 的 blob 对 象 通过 对 象 库 
打包 也 会 进行 存储 优化 。 


10.4 ”移动 文件 


通过 将 welcome.txt 改 名 为 README 文 件 来 测试 一 下 在 Git 中 如 何 移 
动 文件 。Git 提 供 了 git mv 命令 完成 改名 操作 。 





$ git mv welcome.txt README 





可 以 从 当前 的 状态 中 看 到 改名 的 操作 。 





$ git status 

# On branch master 

# Changes to be committed: 

(use "git reset HEAD <file>..." to unstage) 


renamed: welcome.txt -> README 


亲 亲 和亲 宁 





提交 改名 操作 ， 在 提交 输出 中 可 以 看 到 改名 前 后 两 个 文件 的 相似 度 
自分 比 六 3 





$ git commit -m "改名 测试 " 

[master 7aa5ac1] 改名 测试 

1 files changed， © insertions(+)， 0 deletions(-) 
rename welcome.txt => README (100%) 





从 提交 日 志 中 出 现 的 文件 相似 度 可 以 看 出 ，Git 的 改名 操作 得 益 
Git 对 文件 追踪 的 强大 文 持 《文件 内 容 作 为 blob 对 象 保 存在 对 象 库 中 ) 。 
改名 操作 相当 于 对 旧 文 件 执行 删除 ， 对 新 文件 执行 添加 。 实 际 上 完全 可 
以 不 使 用 git mv 命令 ， 而 是 以 git rm 和 和 git add 两 条 命令 取而代之 。 为 了 试 


验 不 使 用 git mv 命令 是 否 可 行 ， 先 撤销 之 前 进行 的 提交 。 


` 撤销 之 前 测试 文件 移动 的 提交 。 





$ git reset --hard HEAD^ 
HEAD is now at 63992fg0 restore file: welcome.txt 





撤销 之 后 welcome.txt 文 件 又 回 米 了 。 





$ git status -s 
$ git ls-files 
welcome.txt 





新 的 改名 操作 不 使 用 git mv 命令 ， 而 是 直接 在 本 地 改名 (文件 移 
动 ) ， 将 welcome.txt 改 名 为 README。 





$ mv welLcome ,txt README 
$ git status -s 

D welcome.txt 
?7 README 





为 了 考验 一 下 Git 的 内 容 奶 踩 能 力 ， 再 修改 一 下 改名 后 的 README 
文件 ， 即 在 文件 末尾 追加 一 行 。 








$ echo "Bye-Bye." >> README 





可 以 使 用 前 面 介绍 的 git add-A 命 令 。 相 当 于 对 修改 文件 执行 git 
add， 对 删除 文件 执行 gitrm， 对 本 地 新 增 文件 执行 git add。 





$ git add -A 





碍 看 状态 ， 也 可 以 看 到 文件 重 命名 。 





$ git status 

# On branch master 

# Changes to be committed: 

(use "git reset HEAD <file>..." to unstage) 


## 
## 
## renamed : welcome.txt -> README 
# 





执行 提交 。 





$ git commit -m "README is from welcome.txt." 
[master c024f34] README is from welcome.txt. 
1 files changed, 1 insertions(+), 0 deletions(-) 
rename welcome.txt => README (73%) 





这 次 提交 中 也 看 到 了 重 命 名 操作 ， 但 是 重 命名 相似 度 不 是 1009%， 
而 是 73%， 这 是 因为 重 命名 后 的 文件 又 追加 了 一 行 。 








10.5 一 个 显示 版 本 号 的 Hello World 


在 本 章 的 一 开始 为 纪念 前 面 的 实践 留 了 一 个 影 ， 叫 作 old_practice。 
现在 再 次 执行 git describe 看 一 下 现在 的 版 本 号 。 





$ git describe 
old_practice-3-gc024f34 





也 就 是 说 ; 当前 工作 区 的 版 本 是 “留影 ”后 的 第 三 个 版 本 ， 提 交 ID 是 
c024f34。 











下 面 的 命令 可 以 在 提交 日 志 中 显示 提交 对 应 的 里 程 碑 (Tag) 。 其 
中 参数 --decorate 可 以 在 提交 DD 的 旁边 显示 该 提交 关联 的 引用 (里程碑 或 
J) 





$ git log --oneline --decorate -4 

co024f34 (HEAD, master) README is from welcome.txt. 
63992f0 restore file: welcome.txt 

7161977 delete trash files. (using: git add -u) 
2b31c19 (tag: old_ practice) Merge commit "acc2f69 





命令 git describe 的 输出 可 以 作为 软件 版 本 号 ， 这 个 功能 非常 有 用 。 
因为 这 样 可 以 很 容易 地 实现 将 发 布 的 软件 包 版 本 和 版 本 库 中 的 代码 对 应 
在 一 起 ， 当 发 现 软件 包 包 含 Bug 时 ， 可 以 最 快 、 最 准确 地 对 应 到 代码 
ss 


下 面 的 Hello World 程 序 束 实现 了 这 个 功能 。 创 建 目 录 src， 并 在 src 
目录 下 创建 以 下 三 个 文件 : 


(1) 文件 : src/main.c 





没 错 ， 下 面 几 行 代 码 就 是 这 个 程序 的 主 代 码 ， 和 输出 相关 的 代码 就 
两 行 ， 一行 显示 “Hello，world.”， 男 外 一 行 显示 软件 版 本 。 在 显示 软件 
版 本 时 用 到 了 宏 _VERSION， 这 个 宏 的 来 源 参 考 下 一 个 文件 。 





#include "version.h" 

#include <stdio.h> 

int 

main() 
printf( "Hello, world.\n" ); 
printf( "version: %s.\n", _VERSION ); 
return ©; 


} 





(2) 文件 : src/version.h.in 


没 错 ， 这 个 文件 名 的 后 级 是 .h.in。 这 个 文件 其 实 是 用 于 生成 文件 
version.h 的 模板 文件 。 在 由 此 模板 文件 生成 version.h 的 过 程 中 ， 安 
_VERSION 的 值 “<version>” 会 动态 替换 。 








#ifndef HELLO_WORLD_VERSION_H 
#define HELLO_WORLD_VERSION_H 
#define _VERSION "<version>" 
#endif 





(3) 文件 : src/Makefile 








这 个 文件 看 起 来 很 复杂 ， 而 且 要 注意 所 有 缩 进 都 是 使 用 一 个 <Tab> 
键 完成 的 缩 进 ， 千 万 不 要 错误 地 写成 空格 ， 因 为 这 是 Makefile 的 格式 要 
求 。 这 个 文件 除了 定义 如 何 由 代码 生成 可 执行 文件 hello 之 外 ， 还 定义 了 
如 何 将 模板 文件 version.h.in 转 换 为 version.h。 在 转换 过 程 中 用 git describe 
命令 的 输出 蔡 换 模板 文件 中 的 <version> 字 符 串 。 











OBJECTS = main.o 
TARGET = hello 
all: $(TARGET) 
$(TARGET): $(0BJECTS ) 
$(CC) -0 $@ $A 人 
main.o: main.c version.h 
version.h: new_header 
new_header : 
@sed -e "s/<version>/$$(git describe)/g" \ 
< version.h.in > version.h.tmp 
@if diff -q version.h.tmp version.h >/dev/null 2>&1; \ 
then \ 
rm version.h.tmp; \ 
else \ 
echo "version.h.in => version.h" ; \ 
mv version.h.tmp version.h; \ 
fi 
clean: 
rm -f $(TARGET) $(OBJECTS) version.h 
.PHONY: all clean 





上 述 三 个 文件 创建 完毕 之 后 ， 进 入 到 src 目 录 ， 试 着 运行 一 下 。 先 执 
行 make 编 译 ， 再 运行 编译 后 的 程序 














hello。 

$ cd src 

$ make 

version.h.in => version.h 
cc -C -0 main.o main.c 
cc -0 hello main.o 


version: old_practice-3-gc024f34. 


和 ae”eeeeeeeeeeeeeeee 


10.6 ”使 用 git add-i 选 择 性 添加 


刚刚 创建 的 Hello World 程 序 还 没有 添加 到 版 本 库 中 ， 在 src 目 录 下 有 
下 列 文 件 : 





$ cd /path/to/my/workspace/demo 
$ ls src 
hello main.c main.o Makefile version.h version.h.in 








这 些 文件 中 hello、main.o 和 version.h 都 是 在 编译 时 生成 的 文件 ， 不 
应 该 加 入 到 版 本 库 中 。 那 么 选择 性 添加 文件 除了 针对 文件 逐一 使 用 git 
add 命 令 外 ， 还 有 其 他 办 法 吗 ? 通过 使 用 -i 参数 调用 git add 就 是 一 个 办 
法 ， 它 提供 了 一 个 交互 式 的 界面 。 





执行 git add-i 命 令 ， 进 入 一 个 交互 式 界 面 ， 首 先 显 示 的 是 工作 区 状 
态 。 显 然 因 为 版 本 库 进行 了 清理 ， 所 以 显得 很 “干净 ”。 





$ git add -i 


staged unstaged path 
** Commands *** 
1: status 2: update 3: revert 4: add untracked 
5: patch 6: diff 7: quit 8: help 
What now> 











交互 式 界 面 显示 了 命令 列表 ， 可 以 使 用 数字 或 加 亮 显示 的 命令 首 字 
母 ， 选 择 相应 的 功能 。 对 于 此 例 需 要 将 新 文件 加 入 到 版 本 库 中 ， 所 以 选 


择 ‘4’ 2 


有 一 于 


What now> 4 

1: src/Makefile 

2: src/hello 

3: src/main.c 

4: src/main.o 

5: src/version.h 

6: src/version.h.in 
d untracked>> 





当选 择 了 “4” 之 后 ， 就 进入 了 “Add untracked” 的 界面 ， 显 示 了 本 地 新 
增 《〈 疝 不 在 版 本 库 中 ) 的 文件 列表 ， 而 且 提 示 符 也 变 了 ， 由 “What 
now>” 变 为 “Add untracked>>”。 依 次 输入 1、3、6 将 源 代码 添加 到 版 本 库 
中 。 








输入 “和 





+ 并 
S 


DO 上 上 whN 疏 号 


untracked>> 1 

: src/Makefile 

: src/hello 
src/main.c 
src/main.o 
src/version.h 

: Src/version.h.in 





, 输入 We 





Add untracked>> 3 

* 1: src/Makefile 

: src/hello 

: src/main.c 

: src/main.o 

: src/version.h 

: Src/version.h.in 


大 


OOOND 





输入 6 





Add untracked>> 6 


: src/Makefile 
: src/hello 
: src/main.c 
: src/main.o 
5: src/version.h 
* 6: src/version.h.in 
Add untracked>> 


* 
入 ODP 








每 次 输入 文件 序号 ， 对 应 的 文件 前 面 都 添加 一 个 星 号 ， 代 表 将 此 文 
件 添加 到 暂 存 区 。 在 提示 符 “Add untracked>>” 处 按 回 车 键 ， 完 成 文件 添 
加 ， 返 回 主 界面 。 





Add untracked>> 
added 3 paths 
*** Commands *** 


1: status 2: update 3: revert 4: add untracked 
5: patch 6: diff 7: quit 8: help 
What now> 





此 时 输入 “1? 碍 看 状态 ， 可 以 看 到 三 个 文件 添加 到 和 暂 存 区 中 。 





What now> 1 


Staged unstaged path 
1 +20/-0 nothing src/Makefile 
2 +10/-0 nothing src/main.c 
+6/-0 nothing src/version.h.in 
*** Commands *** 
1: status 2: update 3: revert 4: add untracked 
5: patch 6: diff 7: quit 8: help 





输入 “7” 退 出 交互 界面 。 


查看 文件 状态 ， 可 以 发 现 三 个 文件 被 添加 到 和 暂 存 区 中 。 





$ git status -s 

A src/Makefile 

A src/main.c 

A src/version.h.in 
?7? src/hello 

?7? src/main.o 


?3 src/version.h 








$ git commit -m "Hello world initialized." 
[master d71ce92] Hello world initialized. 
3 files changed, 36 insertions(+), 0 deletions(-) 
create mode 100644 src/Makefile 
create mode 100644 src/main.c 
create mode 100644 src/version.h.in 


ee | 


10.7 Hello World 引 发 的 新 问题 


到 src 目 录 中 ， 对 Hello World 执 行 编译 。 





$ cd /path/to/my/workspace/demo/src 
$ make clean && make 

rm -f hello main.o version.h 
version.h.in => version.h 

cc -C -0 main.o main.c 

cc -0 hello main.o 











运行 编译 后 的 程序 ， 是 不 是 对 版 本 输出 不 满意 呢 ? 





$ ./hello 
Hello, world. 
version: old_practice-4-gd71ice92. 











之 所 以 显示 长 长 的 版 本 号 ， 是 因为 使 用 了 在 本 章 最 开始 留 的 “ 影 ”。 
现在 为 Hello world 留 下 一 个 新 的 “ 影 ”〈 一 个 新 的 里 程 碑 ) 吧 。 





$ git tag -m "Set tag hello 1.0." he11o_ 1.0 








然后 清除 上 次 编译 结果 后 ， 重 新 编译 和 运行 ， 可 以 看 到 新 的 输出 。 





$ make clean && make 
rm -f hello main.o version.h 
version.h.in => version.h 


cc -C -0 main.o main.c 
cc -0 hello main.o 


version: hello 1.0. 


ee | 


还 不 错 ， 显 示 了 新 的 版 本 号 。 此 时 在 工作 区 查看 状态 ， 会 发 现 工作 
区 “不 干净 ”。 


$ git status 
# On branch master 


# Untracked files: 
(use "git add <file>..." to include in what will be committed) 


main.o 


## 
## 
# hello 
## 
# version.h 


编译 的 目标 文件 和 从 模板 生成 的 头 文件 出 现在 了 Git 的 状态 输出 
中 ， 这 些 文件 会 对 以 后 的 工作 造成 干扰 。 当 写 了 新 的 源 代码 文件 需要 添 
加 到 版 本 库 中 时 ， 因 为 这 些 干扰 文件 的 存在 ， 不 得 不 逐一 挑选 要 添加 的 
文件 。 更 为 严重 的 是 ， 如 果 不 小 心 执行 git add. 或 git add- 人 A 命令 会 将 编译 
的 目标 文件 及 其 他 临时 文件 加 入 版 本 库 中 ， 浪 费 存储 空间 不 说 ， 甚 至 还 


会 造成 冲突 。 


Git 提 供 了 文件 忽略 功能 ， 可 以 用 来 解决 这 个 问题 。 


10.8 ”文件 忽略 





Git 提 供 了 文件 忽略 功能 。 当 对 工作 区 某 个 目录 或 某 些 文件 设置 了 
忽略 后 ， 再 执行 git status 查 看 状态 时 ， 被 忽略 的 文件 即使 存在 也 不 会 显 
示 为 未 跟踪 状态 ， 甚 至 根本 感觉 不 到 这 些 文件 的 存在 。 现 在 就 针对 
Hello world 程 序 目录 试验 一 下 。 











$ cd /path/to/my/workspace/demo/src 
$ git status -s 

?3? hello 

?3? main.o 

?? version.h 











可 以 看 到 src 目 录 下 编译 的 目标 文件 等 显示 为 未 跟踪 ， 每 一 行 开头 的 
两 个 问号 好 像 在 向 我 们 请 求 :“ 快 把 我 们 添加 到 版 本 库 里 吧 ”。 


执行 下 面 的 命令 可 以 在 这 个 目录 下 创建 一 个 名 为 .gitignore 的 文件 
(注意 文件 的 前 面 有 个 点 ) ， 把 这 些 要 忽略 的 文件 写 在 其 中 ， 文 件 名 可 
以 使 用 通配符 。 注 意 : 第 2 行 到 第 5 行 开头 的 右 尖 括 号 是 cat 命 令 的 提示 
符 ， 不 是 用 户 的 输入 。 








$ cat > .gitignore << EOF 
> hello 

> *.0 

> oh 

> EOF 








看 看 写 好 的 .gitignore 文 件 。 每 个 要 忽略 的 文件 显示 在 一 行 。 





$ cat .gitignore 
hello 

*.0 

ol 





再 来 看 看 当前 工作 区 的 状态 。 








$ git status -s 
?7? .gitignore 





把 .gitignore 文 件 添 加 到 版 本 库 中 吧 。 (如 果 不 希 望 添加 到 库 里 ， 也 
不 希望 .gitignore 文 件 带 来 干扰 ， 可 以 在 忽略 文件 中 忽略 自己 。) 











$ git add .gitignore 

$ git commit -m "ignore object files." 

[master b3af728] ignore object files. 

1 files changed, 3 insertions(+), 0 deletions(-) 
create mode 100644 src/.gitignore 





1. 文 件 .gitignore 可 以 放 在 任何 目录 中 


文件 .gitignore 的 作用 范围 是 其 所 处 的 目录 及 其 子 目 录 ， 因 此 如 宋 把 
刚刚 创建 的 .gitignore 移 动 到 上 一 层 目 录 《 仍 位 于 工作 区 内 ) 也 应 该 有 
效 ， 移 动 操作 如 下 : 





git mv .gitignore .. 
git status 
on branch master 
Changes to be committed: 
(use "git reset HEAD <file>..." to unstage) 


亲 半 半 亲 半 半 人 切切 


renamed: .gitignore -> ../.gitignore 





果然 移动 .gitignore 文 件 到 上 层 目 录 ，Hello world 程 序 目 录 下 的 目标 
文件 依然 被 忽略 着 。 


执行 提交 : 





$ git commit -m "move .gitignore outside also works." 
[master 3488f2c] move .gitignore outside also works. 
1 files changed, © insertions(+), 0 deletions(-) 
rename src/.gitignore => .gitignore (100%) 





2. 忽 上 略 文件 有 和 错误， 后 果 很 严重 


实际 上 上， 上面 写 的 忽略 文件 不 是 非 第 好 ， 为 了 忽略 version.h， 结 果 
使 用 了 通配符 *.h 会 把 源码 目录 下 的 有 用 的 头 文件 也 给 忽略 掉 ， 导 致 应 
该 添加 a 到 版 本 库 的 文件 起 记 添 加 。 





在 当前 目录 下 创建 一 个 新 的 头 文件 hello.h。 





$ echo "/* test */"”> hello.h 





在 工作 区 状态 显示 中 看 不 到 hello.h 文 件 。 





$ git status 
# On branch master 
nothing to commit (working directory clean) 








只 有 使 用 了 --ignored 参 数 ， 才 会 在 状态 显示 中 看 到 被 忽略 的 文件 。 





$ git status --ignored -s 
1!1 hello 


1!! hello.h 
1!! main.o 
1! version.h 





要 添加 hello.h 文 件 ， 使 用 git add-A 和 git add. 都 失效 。 无 法 用 这 两 个 
命令 将 hello.h 添 加 到 和 暂 存 区 中 。 





$ git add -A 
$ git add . 
$ git status -s 





只 有 在 添加 操作 的 命令 行 中 明确 地 写 入 文件 名 ， 并 且 提 供 -f 参 数 才 
能 真正 添加 。 





$ git add -f hello.h 

$ git commit -m "add hello.h" 

[master 48456ab] add hello.h 

1 files changed, 1 insertions(+), 0 deletions(-) 
create mode 100644 src/hello.h 








3. 忽 略 只 对 未 跟踪 文件 有 效 ， 对 于 已 加 入 版 本 库 的 文件 无 效 


文件 hello.h 添 加 到 版 本 库 后 ， 葡 不 再 受到 .gitignore 设 置 的 文件 忽略 
所 影响 了 ， 对 hello.h 的 修改 都 会 立刻 被 跟踪 到 。 这 是 因为 Git 的 文件 忽略 
只 是 对 未 入 库 的 文件 起 作用 。 





$ echo "/* end */" >> hello.h 

$ git status 

# On branch master 

# Changed but not updated: 

(use "git add <file>..." to update what will be committed) 

(use "git checkout -- <file>,..." to discard changes in working directory) 


## 
## 
## 
## modified: hello.h 
## 
n 


oO changes added to commit (use "git add" and/or "git commit -a") 


偷懒 式 提 交 。 《使 用 了 -a 参 数 所 区， 不 用 预先 执行 git add 命 令 。 ) 











$ git commit -a -m "偷懒 了 ， 直 接 用 -a 参数 直接 提交 。 由 
[master 613486c] 偷懒 了 ， 直 接 用 -a 参数 直接 提交 
1 files changed, 1 insertions(+), 0 dl et ne 





















































4. 本 地 独 理 式 忽 略 文件 


文件 .gitignore 设 置 的 文件 忽略 是 共享 式 的 。 之 所 以 称 其 为 “共享 
we ee ie 
本 库 共 享 给 他 人 《克隆 ) ， 或 者 把 版 本 库 推 送 (PUSH) 到 集中 式 的 服 
务 器 (或 他 人 的 版 本 库 ) 时 ， 这 个 忽略 文件 就 会 出 现在 他 人 的 工作 区 
中 ， 文 件 忽略 在 他 人 的 工作 区 中 同样 生效 。 








与 “ 共 诗 式 ” 忽 略 对 应 的 是 “ 独 享 式 ”忽略 。 独 至 式 忽略 就 是 不 会 因为 
版 本 库 共 人 享 ， 或 者 版 本 库 之 间 的 推送 传递 给 他 人 的 文件 忽略 。 独 享 式 忽 
略 有 两 种 方式 : 


: 一 种 是 针对 具体 版 本 库 的 “ 独 享 式 ”忽略 。 即 在 版 本 库 .git 目 录 下 
的 一 个 文件 .git/info/exclude 来 设置 文件 急 略 。 


` 另外 一 种 是 全 局 的 “ 独 享 式 ” 和 忽略。 即 通过 Git 的 配置 变 
cofte.excludesfile 指 定 的 一 个 忽略 文件 ， 其 设置 的 忽略 对 所 有 本 地 版 本 库 
均 有 效 。 





RANGE 有 圣 式 的 
文件 忽略 ， 哪 些 情况 通过 .git/info/exclude 设 置 只 对 本 地 有 效 的 独 享 式 文 
件 忽 略 ， 这 取决 于 要 设置 的 文件 忽略 是 否 具 有 普 避 意义 。 如 末 文 件 忽 略 
对 于 所 有 使 用 此 版 本 库 工作 的 人 都 有 荔 ， 殊 通过 在 版 本 库 相 应 的 目录 下 
创建 一 个 .gitignore 文 件 建立 忽略 ; 否则， 如果 是 需要 忽略 工作 区 中 创建 
的 一 个 试验 目录 或 试验 性 的 文件 ， 则 使 用 本 地 忽略 。 











例如 ， 我 的 本 地 就 设置 着 一 个 全 局 的 独 齐 的 文件 忽略 列表 《〈 这 个 文 
件 名 可 以 随意 设置 ) : 





$ git config --global core.excludesfile /home/jiangxin/ .gitignore 
$ git config core.excludesfile 

/home/jiangxin/ .gitignore 

$ cat /home/jiangxin/ .gitignore 

~ # vim 临时 文件 





.pyc # python 的 编译 文件 
.* .MMX # 不 是 正则 表达 式 哦 ， 因 为 FreeMind-MMX 的 辅助 文件 以 点 开头 















































5.Git 忽 略语 法 
关于 Git 的 忽略 文件 的 语法 规则 再 多 说 几 人 句 : 
` 忽略 文件 中 的 空 行 或 以 井 号 (#) 开始 的 行 会 被 忽略 。 


可 以 使 用 通配符 ， 参 见 Linux 手 册 : glob (7) 。 例 如 : 星 号 (*) 
代表 任意 多 字符 ， 问 号 〈? ) 代表 一 个 字符 ， 方 括号 ([abc]) 代表 可 选 


` 如 果 名 称 的 最 前 面 是 一 个 路 径 分 隔 符 (/) ， 表 明 要 忽略 的 文件 
在 此 目录 下 ， 而 非 子 目录 的 文件 。 


. 如 果 名 称 的 最 后 面 是 一 个 路 径 分 隔 符 (/) ， 表 明 要 忽略 的 是 整 
个 目录 ， 同 名 文件 不 和 忽略， 否则 同名 的 文件 和 目录 都 忽略 。 


通过 在 名 称 的 最 前 面 添 加 一 个 感叹 号 〈! ) ， 代 表 不 忽略 。 


下 面 的 文件 忽略 示例 ， 包 含 了 上 述 要 点 : 





# 这 是 注释 行 - - 被 忽略 
# 忽略 所 有 以 .a 为 扩展 名 的 文件 。 
# 昌 是 1ib.a 文件 或 目录 不 要 忽略 ， 即 使 前 面 设 置 了 对 * .a 的 忽略 。 
/TODO # 只 忽略 此 目录 下 的 TODO 文件 ， 子 目录 的 TODO 文件 不 忽略 。 
# 
# 






















































































build/ 忽略 所 有 build/ 目录 下 的 文件 。 
docV* .txt 忽略 文件 如 docVnotes .txt， 但 是 文件 如 doc/server/arch.txt 不 被 忽略 。 














10.9 文件 归档 


如 果 使 用 压缩 工具 (tar、7zip、winzip、rar 等 ) 将 工作 区 文件 归 
档 ， 一 不 小 心 会 把 版 本 库 〈.git 目 录 ) 包含 其 中 ， 甚 至 将 工作 区 中 的 忽 
上 略 文件 、 临 时 文件 也 包含 其 中 。Git 提 供 了 一 个 归档 命令 : git archive， 
可 以 对 任意 提交 对 应 的 目录 树 建立 归档 。 示 例如 下 : 








. 基于 最 新 提交 建立 归档 文件 latestzip。 





$ git archive -0 latest.zip HEAD 





. 只 将 目录 stc 和 doc 建 立 到 归档 pattial.taf 中 。 





$ git archive -0 partial,tar HEAD src doc 





` 基于 里 程 碑 v1.0 建 立 归档 ， 并 且 为 归档 中 的 文件 添加 目录 前 缓 
1.0。 





$ git archive --format=tar --prefix=1.0/ v1.0 | gzip > foo-1.0.tar.gz 





在 建立 归档 时 ， 如 果 使 用 树 对 象 太 进行 归档 ， 则 使 用 当前 时 间作 为 
归档 中 文件 的 修改 时 间 ， 而 如 果 使 用 提交 ID 或 里 程 碑 等 ， 则 使 用 提交 建 
并 的 时 间作 为 归档 中 文件 的 修改 时 间 。 


如 采 使 用 tar 格 式 建立 归档 ， 并 且 使 用 提交 ID 或 里 程 碑 ID， 还 会 把 提 
交 ID 记 录 在 归档 文件 的 文件 头 中 。 记 录 在 文件 头 中 的 提交 ID 可 以 通过 git 


tar-commit-id 命 令 获 取 。 
如 果 和 希望 在 建立 归档 时 忽略 某 些 文件 或 目录 ， 可 以 通过 为 相应 文件 


或 目录 建立 export-ignore 属 性 加 以 实现 。 有 具体 参见 本 书 第 8 篇 第 41 章 “41.1 
局 性 人。 





第 11 章 “历史 穿梭 








经 过 了 之 前 众多 的 实践 ， 版 本 库 中 己 经 积累 了 很 多 次 提交 了 ， 从 下 
面 的 命令 中 可 以 看 出 有 14 次 提交 





$ git rev-list HEAD | wc -1 
14 





有 很 多 工具 可 以 研究 和 分 析 Git 的 历史 提交 ， 在 前 面 的 实践 中 ， 我 
们 已 经 多 次 用 到 相关 的 Git 命 令 查 看 历史 提交 、 碍 看 文件 的 历史 版 本 、 
进行 差异 比较 等 。 本 章 除 了 对 之 前 用 到 的 相关 Git 命 令 作 一 下 总 结 外 ， 
还 要 再 介绍 几 球 图 形 化 的 客户 新。 


茜 


由 


11.1 图 形 工具 : gitk 


tk 是 最 早 实 现 的 一 个 图 形 化 的 Git 版 本 库 浏览 器 软件 ， 基 于 TcV/Tk 
实现 ， 因 此 gitk 非 常人 简洁 ， 本 里 就 是 由 一 个 1 万 多 行 的 tcl 脚本 写成 的 。 
tk 的 代码 已 经 和 Git 的 代码 放 在 了 同一 个 版 本 库 中 ，gitk 随 Git 一 同 友 
布 ， 不 用 特别 地 安装 即 可 运行 。gik 可 以 显示 提交 的 分 支 图 ， 可 以 显示 
提交 、 文 件 、 版 本 间 的 差异 等 。 





在 版 本 库 中 调用 gitk， 束 会 浏览 该 版 本 库 ， 显 示 其 提交 的 分 文 图 。 
外 tk 可 以 像 命令 行 工具 一 样 使 用 不 同 的 参数 进行 调用 。 


显示 所 有 的 分 支 。 





$ gitk --all 





` 显示 2 周 以 来 的 所 有 提交 。 





$ gitk --since="2 weeks ago" 





" 显示 某 个 里 程 碑 (v2.6.12) 以 来 ， 针 对 某 些 目录 和 文件 
(include/scsi 目 录 和 dtivets/scsi 目 录 ) 的 提交 。 





$ gitk v2.6.12.. include/scsi drivers/scsi 





图 11-1 就 是 在 DEMO 版 本 库 中 运行 gitk--all 的 显示 。 


File Edit View 


偷 俩 了 ， 豆 招 用 -3 参 权 页 报 揭 。 
@ addhaelloh 
二 move .gitignore outside also works 


@ ignore objeci files, 
Helio world initiallzed, 
多 README is from welcome.txt. 


@ restore file: welcome txt 
delete trash files. (using: git add -u) 
[stash | 


WIP on master 2bS1c19 Merge ccj 


index on master 2b31c19 Merge commit ‘ac 
Merge commit 'acc2f69' 
commit in detached HEAD mode 
| does master follow this new comrmit? 
章 which version checked in? 
便 whodoecs commit? 
@ initialized 


= gitk: demo = 


| Jiang Xin <jiangxin@ossxp com> 
Jiang Xin <jiangxin@ossxp com> 
| Jiang Xin <jiangxin@ossxp com> 
Jiang Xin <jiangxin@ossxp.com> 
Jiang Xin <jiangxin@ossxp.com> 
[Jiang Xin <jlangxin@ossxp.com> 
Jiang Xin <jiangxin@ossxp com> 
[Jiang Xin <jiangxin@ossxpcom> 
Jiang Xin <jlangxin@ossxp comn> 
Jiang Xin <jiangxin@ossxpcom> 
Jiang Xin <jiangxin@ossxp.com> 
Jiang Xin <jiangxin@ossxp.com> 
| Jiang Xin <liangxin@ossxp com> 
Jiang Xin <jiangxin@ossxp com> 
| Uiang Xin <jiangxin@oaaxp.com> 
Jiang Xin <jiangxin@ossxp.com> 





1 2010-12-07 19.43:39 
2010:12:07 193910 
2010-12-07 19:34:37 
2010-12-07 19.21:39 
2010-12-07 18:33:45 
| 2010-12-07 14:50:02 
| 2010.12.07 14:3257 
2010-12-07 14:0215 
2010-12-07 11.55.24 
2010-12-07 11:53:24 
2010-12-05 15:51:25 
2010-12-05 15.43:24 
| 2010-12-04 1 之 13:05 
2010-11-29 17:23:01 
2010.11.29 11:00:06 
| 2010-11-28 1248:26 





SHA11D: Fas el rr | 
Find _ next | pe | commit carting: = et | Mid = 


Search i 


入 Dif 、 Old version \ Newversion Linesofcontext: [3 于 norespacecl ||Comments 


README 
: Jiang Xin <jiangxineossxp ,con> 2010-12-07 18:33:45 wearc 
:+ Jiang Xin <jiangxin@ossxp.com> 2010-12-08 09:46:35 | 3 





»w Patch 人 Tree 


Maketile 
2da53d32759c43568c324 4bA3c50b? (README is From mainc 

byaf7282919d462034fc9d58fga939e0d5112a7dF lignore object £; g 
Branch: master version.h.in 


Follows: old practice 


Proerenica: 











图 11-1 gi 人 k 查 看 DEMO 版 本 库 
从 图 11-1 中 可 见 不 同 颜色 和 形状 区 分 的 引用 : 
` 绿色 的 mastet 分 支 。 

黄色 的 hello_1.0 和 old_practice 里 程 碑 。 


灰色 的 stash。 


gitk 使 用 Ta/Tk 开 发 ， 在 显示 上 没有 系统 中 原生 图 形 应 用 那么 漂亮 
的 界面 ， 其 至 可 以 用 丑陋 来 形容 。gitk 只 能 用 于 版 本 库 浏览 ， 如 果 要 使 





用 TclWTk 图 形 界面 进行 提交 则 需要 使 用 另外 的 命令 : git gui (或 git 
citool) 命令 ， 不 过 下 面 将 要 介绍 的 gitg 和 ggit 在 易 用 性 上 比 gitk 及 git gui 
进步 了 不 少 。 





11.2 图形 工具 : gitg 


gitg 是 使 用 GTK+ 图 形 库 实 现 的 一 个 Git 版 本 库 浏览 器 软件 。Linux 下 
最 著名 的 Gnome 柴 面 环境 使 用 的 就 是 GTK+， 因 此 在 Linux 下 gitg 有 着 非 
常 漂亮 的 原生 的 图 形 界面 。gitg 不 但 能 够 实现 gitk 的 全 部 功能 ， 即 浏览 提 
交 历 史 和 文件 ， 还 能 帮助 执行 提交 。 


在 Linuxz 上 安装 gitg 很 简单 ， 例 如 在 Debian 或 Ubuntu 上， 直接 运行 
面 的 命令 就 可 以 进行 安装 。 





$ sudo aptitude install gitg 








安 半 完毕 后 就 可 以 在 可 执行 路 径 中 找到 gitg。 





$ which gitg 
/usr/bin/gitg 











为 了 演示 gitg 具 备 提交 功能 ， 先 在 工作 区 做 出 一 些 修 改 。 


(1) 删除 没有 用 到 的 hello.h 文 件 。 





$ cd In 
$ rm src/hello.h 





(2) 在 README 文 件 后 面 追加 一 行 。 





$ echo "Wait..." >> README 





(3) 查看 当前 工作 区 的 状态 。 








$ git status -s 
M README 
D src/hello.h 





现在 可 以 在 工作 区 下 执行 gitg 命 令 。 





$ gitg & 





图 11-2 束 是 gitg 的 默认 界面 ， 显 示 了 提交 分 文 图 ， 以 及 选中 提交 的 
提交 信息 和 变更 文件 列表 等 。 


gitg - demo (master) 


Branch: master Sf | | 

Subject |Author |pate = | 
OE wIP on master: 2b31c19 Merge commit ‘acc2f69 Jiang Xin 2010 年 12 月 07 日 星期 二 11 时 53| 
口 Unstaged changes 2010 年 12 月 08 日 星期 三 14 时 32 
伦 辣 了 ， 直 接 用 -a 参数 直接 提交 ， Jiang xin 2010 年 12 月 07 日 星期 二 19 时 43| 
add hello h Jiang Xin 2010 年 12 月 07 日 星期 二 19 时 39| 
move gitigNnore outside also works. Jiang Xin 2010 年 12 月 07 日 星期 二 19 时 34 
ignare nhject files Jiang Xin 2n10 年 1 月 N07 日 是 期 一 
Hello world initialized jiang Xin 2010 年 12 月 07 日 星期 二 
README is from welcome txt. Jiang Xin 2010 年 12 月 07 日 星期 二 14 时 50| 
restore file; welcome txt Jiang Xin 2010 年 12 月 07 日 星期 二 14 时 32| 





delete trash files, (Usiny’ yit add -u) Jiang Xin 2010 御 12 月 07 日 星期 二 14 时 02| 
| 

Merge commit 'acc2f69， jiang Xin 2010 年 12 月 05 日 星期 日 15 时 51| 
commit in detached HEAD mode. Jiang Xin 2010 年 12 月 05 日 星期 日 15 时 43| 


Datoils | 吉本 


SHA: d71ce9255b3b08c718810e4e31760198dd6da243 
Author: jiang Xin 
Date: 2010 年 12 月 07 日 星期 二 18 时 33 分 45 秒 
Subject: Hello world initialized. 
Parcnt; co024f34ede5Id2759c4d568c324065e4b43c50b7 (README 15 frorm welcome .txt.) 





口 srcMakefile | | Hetto world initialized. 
[3 src/main.c 


Signed-off-by: Jiang Xin <]jiangxin@ossxp. com> 
[3 src/version hin 





oaded 16 revisions in 0.245 





图 11-2 pgitg 查 看 DEMO 版 本 库 


从 图 11-2 中 可 以 看 见 用 不 同 颜 色 的 标签 显示 的 状态 标识 〈 包 括 引 
用 ) : 


. 檬 色 的 masterf 分 支 。 
黄色 的 hello_1.0 和 old_practice 里 程 碑 。 


` 粉色 的 stash 标 签 。 


-白色 的 显示 工作 区 非 暂 存 状 态 的 标签 。 





点 击 gitg 下 方 窗口 的 标签 "tree”， 会 显示 此 提交 的 目录 树 ， 如 图 11-3 
所 示 。 


| Merge commit 'acc2f69， Jiang Xin 2010 年 12 月 05 日 星期 日 15 时 51 
| commit in detached HEAD mode jang Xin 2010 年 12 月 05 日 星期 日 15 时 43 |v| 
Details Tree| 
国 src 大 nclude "version.1 
| : 2#include <stdio.h> 
| main.c 
[| 四 manc< .用 
| Makefile 4 int 
司 version hin 5 main() 
国 README 6 { 
9 7 printf( "Hello, world.\n" ); 
41.8 printf( "version: %s.\n", _VERSION ); 
9 return 9; 
19 } 
11 








oaded 16 revisions in 0.24s 


图 11-3 ”gitg 查 看 目录 树 


提交 功能 是 gitg 的 一 大 特色 。 点 击 gitg 顶 部 窗口 的 commit 标 签 ， 显 示 


如 图 11-4 的 界面 。 


三 giftg- demo fmaster) 





Context: | 





Unstaged Commit message Staged 
国 README 
会 src/hello.h 





3 


口 Amend 
口 Add signed-off-by 











oaded 16 revisions in 0.07s 





图 11-4 ”gitg 的 提交 界面 











图 11-4 中 ， 左 下 方 窗口 显示 的 是 未 更 新 到 和 暂 存 区 的 本 地 改动 。 鼠 标 
石 击 ， 在 弹出 末 单 中 选择 “Stage”， 如 图 11-5 所 示 。 


Wi 

Changes 

| diff git a/README b/README 

index 51dbfd2. ,ceaf61l1b 100644 
Ga -1,3 +1,4 @@ 

1| 1 Hello. 

2| 2 Nice to meet you. 

3| 3 Bye-Bye. 


Unstaged Commit message Staged 


| 
> README 
忆 Stage 
便 srcihello h Revert 
9 


口 Amend 
| 口 Add signed-off-by 

















oaded 16 revisions in 0.07s 


图 11-5 8gitg 提 交界 面 中 的 弹出 菜单 


当 把 文件 README 添 加 到 和 暂 存 区 后 ， 可 以 看 到 README 文 件 出 现 


在 右 下 方 的 窗口 中 ， 如 图 11-6 所 示 。 


gitg- demo (master) 
File Edit View Repository Help 
History Commit | 
Changes 
diTT AA A 
| deleted file mode 106644 
GO -1,2 +0,0 GG 
1! BAS tess 
2| =/endwy 
3| 6 
Unstaged commit message 


Context: | 有 J 13 


Staged 





局 src/hello.h 


8 README 





OAmend 
口 Add signed-off-by 








oaded 17 revisions in 0.07s 


< 人 commit| 





图 11-6 ”gitg 提 交 文 件 加 入 暂 存 区 


此 时 如 果 回 到 提交 历史 查看 界面 ， 可 以 看 到 在 “stash” 标 签 的 下 方 ， 
同时 出 现 了 “staged” 和 “unstaged” 两 个 标签 分 别 表示 暂 存 区 和 工作 区 的 状 


态 ， 如 图 11-7 所 示 。 








ej =gfktg-demofmaster) :HHT © 
File Edit View Repository Help 
History | Comm 


Branch: master vv | 凡 


| subject Author Date 























oO WIP on master: 2b31c19 Merge commit ‘acc2f69' Jiang Xin 2010 年 12 月 07 日 星期 二 11 时 53| 
O Unstaged changes 2010 年 12 月 08 日 星期 三 14 时 53 
?ED 偷懒 了 ， 直 接 用 -a 参数 直接 提交 。 Jiang Xin 2010 年 12 月 07 日 星期 二 19 时 43 层 








Details [rreel 


SHA: 0000000000000000000000000000000000000000 
Author: 
Date: 2010 年 12 月 08 日 星期 三 14 时 53 分 32 秒 
Subject: Staged changes 
Parent: 








| 读 README | 





| 2| 2 Nice to meet you. 
] 3| 3 Bye-Bye. 
4 +Walt,.. 





oaded 17 revisions In 0.07s 


图 11-7 gitg 界 面 中 的 staged 和 unstaged 标 签 


当 通 过 gitg 的 界面 选择 好 要 提交 的 文件 (加 入 暂 存 区 ) 之 后 ， 执 行 
提交 ， 如 图 11-8 所 示 。 


= gitg - demo (master) 三 
File Edit View Repository Help 





Changes Context: | 
ey 


Unstaged ~ Commit message staged 
试 着 使 用 gitg 进行 提交 ， | 8 README 


| 一 src/hello.h 











oaded 17 revisions in 0.07s 





图 11-8 ”gitg 执 行 提交 


图 11-8 的 提交 说 明 对 话 框 的 下 方 有 两 个 选项 ， 当 选择 了 “Add signed- 
off-by” 选 项 后 ， 在 提交 日 志 中 会 自动 增加 相应 的 说 明文 字 。 图 11-9 可 以 
看 到 刚刚 的 提交 已 经 显示 在 提交 历史 的 最 顶端 ， 在 提交 说 明 中 出 现 了 
Signed-off-by 文 字 说 明 。 





Ot demo (Measter) = 


File Edit View Repository Help 


History |commit | 


Branch: master v | 名 
Subject | Author | Date | 


oO WIP on master: 2b31c19 Merge commit 'acc2f69' Jiang Xin 2010 年 12 月 07 日 星期 二 11 时 53 
[master IO :el rES Jiang Xin 2010 年 12 月 08 日 星期 三 15 时 02 
偷情 了 ， 直接 用 -a 参数 直接 提交 ， Jiang Xin 2010 年 12 月 07 日 星期 二 19 时 43 一 








Details [mee] 
SHA: ca23a19627df30d89dc47821ef21379d1lc2cl7ab 
Author: Jiang Xin 
Date: 2010 年 12 月 08 日 星期 三 15 时 02 分 19 秒 
Subject: 试 着 使 用 gitg 进行 提交 。 
Parent: 613486c17842d139871e0flb0e9191d2b6177c9f ( 粉 坎 了， 让 接 用 -a 贿 数 直接 控 交 ，) 


| | | 试 荐 使 用 gitg 进行 提交 。 
鲁 srclhello h 
J Signed-off-by: Jiang Xin <]jiangxin@ossxp. com> 


-~Qit a/README b/README 
index 5ldbfd2..ceaf01b 100644 








oaded 16 revisions in 0.07s 


图 11-9 ”gitg 显 示 的 最 新 提交 


gitg 还 是 一 个 比较 新 的 项 目 ， 在 本 文 撰写 的 时 候 ，gitg 才 是 0.0.6 版 
本 ， 相 比 下 面 要 介绍 的 qgit 还 缺乏 很 多 功能 。 例 如 gitg 没 有 文件 的 
blame《“ 退 调 ) 界面 ， 也 不 能 直接 将 文件 检 出 ， 但 古 gitg 整 体 的 界面 风 
格 ， 以 及 易 用 的 提交 界面 给 人 的 印象 非常 深刻 。 


11.3 图 形 工具 : ggit 


前 面 介 绍 的 gitg 是 基于 GTK+ 这 一 Linux 标 准 的 图 形 库 ， 那 么 也 许 有 
读者 已 经 猜 到 qgit 是 使 用 Linux 另 外 一 个 著名 的 图 形 库 QT 实现 的 。QI 的 
知名 度 不 亚 于 GTK+， 是 著名 的 KDE 桌 面 环境 用 到 的 图 形 库 ， 也 是 蓄 势 
待 发 准备 和 Android 一 较 高 低 的 MeeGo 的 UI 核 心 。qgit 目 前 的 版 本 是 2.3， 
相 比 前 面 介 绍 的 gitg， 其 经 历 的 开发 周期 要 长 了 不 少 ， 因 此 也 提供 了 更 
多 的 功能 





在 Linux 上 安装 qgit 很 简单 ， 例 如 在 Debian 或 Ubuntu 上 ， 直 接 运 行 
面 的 命令 就 可 以 进行 安装 。 





$ sudo aptitude install qgit 





安 闭 完毕 就 可 以 在 可 执行 路 径 中 找到 qgit。 





$ which qgit 
/usr/bin/qgit 





qgit 和 gitg 一 样 不 但 能 够 浏览 提交 历史 和 文件 ， 还 能 帮助 执行 提交 。 
为 了 测试 提交 ， 将 回 深 在 上 一 节 所 做 的 提交 ， 


` 使 用 重 置 命令 回 深 最 后 一 次 提交 。 





$ git reset HEADA^ 

Unstaged changes after reset : 
M README 

M src/hello.h 





` 查看 当前 工作 区 的 状态 。 





$ git status 
# On branch master 
# Changed but not updated: 
(use "git add/rm <file>..." to update what will be committed) 
(use "git checkout -- <file>,..." to discard changes in working directory) 


## 

## 

# 

## modified: README 

## deleted: src/hello.h 
# 
n 


0 changes added to commit (use "git add" and/or "git commit -a") 





现在 可 以 在 工作 区 下 执行 qgit 命 令 。 





$ qgit & 





启动 qggit， 首 先 弹 出 一 个 对 话 框 ， 提 示 对 显示 的 提交 范围 和 分 支 范 
围 进行 选择 ， 如 图 11-10 所 示 。 


Vv, Working dir v, Allbranches ww Whole history 


Additional options: 


--all 


wj Show this dialog when opening a repository 





图 11-10”qgit 启 动 对 话 框 


对 所 有 的 选择 打 钓 ， 显 示 下 面 的 qgit 的 默认 界面 。 其 中 包括 了 提交 
分 文 图 ， 以 及 选中 提交 的 提交 信息 和 变更 文件 列表 等 ， 如 图 11-11 所 


小 。 


/Imy/workspace/demo - QGIt 
File Edit View Actions Help 


站 QO0OD BD shortloo i 2 Ce | 071ce925503008c71881004e31760198dd6d3243 


Short Log Author 


人 Working Dir 

偷懒 了 ， 直 接 用 -a 考 数 直接 提交 。 jiang Xin<jiangxin@ossxp.com 
add hello.h jiang Xin<jiangxin@ossxp.com 
move .gitignore outside also works. Jiang Xin<jiangxin@ossxp.com 
ignore object files iang Xin<jiangxin@ossxp.com 
[hello 10 EE G 
README is from welcome tx Vv Check working dir jiang xin<jiangxin@ossxp.com 
restore file: welcome txt jiang Xin<jiangxin@ossxp.com 
delete trash files. (using: git View patch Ctri+P jiang xin<jiangxin@o0ssxp com 
区 FE WIP on master. 2 Extemat difr CtritD Jiang Xin<jiangxin@ossxp.comz 
index on master: 2b31c19 | I jiang Xin<jiangxin@ossxp.com 
[old practice] Merge commit Make branch... jiang Xin<jiangxin@ossxp com 
commit in detached HEAD r jiang Xin<jiangxin@ossxp.com 
does master follow this new Make tag... jiang Xxin<jiangxin@ossxp.com 


Delete tag.., 
到 Sove patch... EE 


ter src/rmain c 
Author jiang Xin<jiangxin@ossx src/version.h.in 


Author date 10-12-7 PM6:33 hello 1.0 
Parent README is from welcom old ti 
Chlld ignore object files. 

Branch master (偷懒 了 ， 直 按 用 -a 考 炊 直接 提交 。) 








Tag: hello_1.0 [Set tag hello 1.0.] 





图 11-11 ggit 主 界面 


从 图 11-11 中 可 以 看 见 用 不 同 闫 色 的 标签 显示 的 状态 标识 (包括 引 
用 ) : 


绿色 的 master 分 支 。 
. 黄色 的 hello_1.0 和 old_practice 里 程 碑 。 


" 灰色 的 stash 标 签 ， 显 示 了 创建 时 候 的 位 置 ， 并 将 其 包含 的 针对 暂 
存 区 状态 的 提交 也 显示 了 出 来 。 


最 顶端 显示 一 行 绿色 背景 的 文字 : 工作 区 有 改动 。 





dqgit 的 右键 菜单 非常 丰富 ， 图 11-11 显 示 了 鼠标 右 击 提交 时 显示 的 弹 
出 菜单 ， 可 以 创建 、 切 换 标签 或 分 文 ， 可 以 将 提 区 导出 为 补丁 文件 。 


点 击 qgit 右 下 方 的 变更 文件 列表 窗口 ， 可 以 选择 将 文件 检 出 或 直接 
查看 ， 如 图 11-12 所 示 。 




















Hello world Initiallzed. aup 站 view patch ctn+P 
Author jang Xin<jiangxin@ossxp.com> - View file Ctrl+HA 
Author date 10-12-7 PM6:33 wd 电 
Parent README is from welcome txt 区 STO er DY ree 
Child iqnore obiect files 六 Save file as... Ctrl+S 
Branch master ( 偷 司 了 ， 真 按 用 -a 考 数 真 述 棍 交 。) v External diff.., Ctriin 
| Tagi hello 1.0 [Set tag hello 1.0,] Zz 





图 11-12 ”ggit 检 出 和 查看 文件 界面 


要 想 显 示 目 录 树 ， 键 入 大 写字 母 T， 或 者 单 击 工具 条 上 的 图 标 
， 就 会 在 左 侧 显示 目录 树 窗口 ， 如 图 11-13 所 示 。 





书 /Imy/workspace/demo - QGIt wa <= -下 x 
File Edit View Actions Help 
相思 有 日 日 后 、 品 否 | shortlog v | BB d7lce9255b3b08c718810e4e317601980d6da243 


Bevict | [| 
Short Log A 


2 MaiN.c master | 日 授 用 -a 考 笋 返 提 交 。 
| j version hin add hello h 
BB SED move .gitignore outstde also works. 
gnore object files. 

hello 1 OTHE 
README is from welcome txt 
restore flle: welcome txt 
delete trash files. (using: git add -U) 
区 BE WP on master: 2b31c19 Merge commit ‘acc2f69' 
index on master: 2b31c19 Merge commit 'acc2f69: 
[Gid 5racticel Merge commit ‘acc2769' 
commit in detached HEAD mode. 
does master follow this new commit? 


入 src/Makefile 


‘ap We | src/main ec 
Author jiang | src/version h in 
Xin<jiangxin@ossxp.com> 


Author ”10-12-7 PM6:-33 
date 





图 11-13 ”ggit 目 录 树 视图 


图 11-13 中 也 显示 了 目录 树 中 弹出 的 右键 菜单 。 当 选择 查看 一 个 文 
件 时 ， 会 显示 此 文件 的 追溯 ， 即 显示 每 一 行 是 在 哪个 版 本 由 谁 修改 的 。 
追 斋 窗口 见 图 11-14 右 下 方 的 窗口 。 


局 Imy/workspace/demo - QGiIt 


6556 
Ble Edt View Actions Help 
QO0DT\ BD sh vv 








| | ? FR | 071ce9255bD3b08c718810e4e31760198dd6da243 
IReviist| README | 












| 本 | 
nn 国 Bae? Vile 5 


;Working d nangt 

README is from welcome txt, 
restore file: welcome txt 
delete trash files. (using: git add -U) 
which version checked in? 
initialized. 







PNWpU 






”Hello. 
ae Nice to meet you. 
”Bye-Bye., 
Wait... 





图 11-14 ”ggit 中 的 追溯 界面 





qgit 也 可 以 执行 提交 。 选 中 ggit 顶 部 窗口 最 上 一 行 “Working dir 
changes”， 鼠 标 右 击 ， 显 示 的 弹出 沫 单 包含 了 “Commit…” 选 项 ， 如 图 11- 
15 所 示 。 


局 /Imy/workspace/demo - QGIt 











OOOG OO 
Fle Edt View Actions Help 
国 鸭 四 O 可 下 下 Shortlog v 他 多 | 5000000000000000000000000000000000000000 | 
RevIst README ea 
Author 人 人 





add hello.h 
move .gitignore outside also works,. 


ignore object fiiles. 
国人 Hao world initialized 


外 
4 


# On branch master 


# Changed but not updated:; 


# (use “git add/rm <file>,.,,” to update what will be committed) 


# (use "git checkout »- <file>.." to discard changes in working 
directory) 
要 


图 11-15 ”从 ggit 弹 出 菜单 选择 提交 


点 击 弹出 菜单 中 的 “Commit...”， 显 示 如 图 11-16 所 示 的 对 话 框 。 


File Index status 
ww README Not updated in index 
ww src/hello.h Not updated in index 


Commit message (first line is the subject): 


所 
# 
# On branch master 
# Changed but not updated: 
(use "git add/rm <file>..." to update what will be committed) 
(vse "git checkout -- <file>..." to discard changes in working directory) 


modified: README 
deleted: src/hello.h 





Settings Cancel Update Index Commit 


图 11-16 ”ggit 提 交界 面 


如 图 11-16 所 示 ， 目 动 选 中 了 所 有 的 文件 。 上 方 窗口 的 选中 文件 目 
前 的 状态 是 “Not updated in index”， 也 就 是 说 尚未 添加 到 和 暂 存 区 。 


使 用 gqgit 做 提交 ， 只 要 选择 好 要 提交 的 文件 列表 ， 即 使 未 添加 到 暂 
存 区 ， 也 可 以 直接 提交 。 在 下 方 的 提交 窗口 中 写 入 提交 日 志 ， 点 
击 “Comnmit” 按 钮 开始 提交 ， 如 图 11-17 所 示 。 








Commit changes 


Index status 
ww README Not updated in index 
wj srdhelio.h Not updated in index 


ommit message (first line is the subject): 
测试 使 用 qgit 提交 


# On branch master 


# Changed but not updated: 
天 (use "git add/rm <file>..." to update what will be committed) 
(use "git checkout -- <file>..." to discard changes in working directory) 


modified: 


Line: 1 Col: 18 Settings | | Cancel | | Update Index 


图 11-17 ggit 中 编辑 提交 说 明 








提交 完毕 返回 qgit 主 界面 ， 在 显示 的 提交 列表 的 最 上 方 ， 原 来 显示 
的 “Working dir changes” 已 经 更 新 为 “Nothing to commit”， 并 且 可 以 看 到 
刚刚 的 提交 已 经 显示 在 提交 历史 的 最 顶端 ， 如 图 11-18 所 示 。 


站 
Eee Edt View Actions Help 
OOOD\ BD shtog vv 


add helloh 
move .gitignore outside also works. 


Author date 10-12-8 PM4:27 

Parent 3 -a 尖 

Chlld Nothing to commit 

Follows helio_1.0 (Hello world initialized.) 
测试 使 用 gqgit 提交 。 


人 


/Imy/workspace/demo - QGIt 


| 3 多 | 1822b4aeed5de74f949c9faa5b281001eb5439444 


Le [下 xj 





jiang Xin<jiangxin@ossxp.com 
jiang xin<jiangxin@ossxp.com 
Jiang Xin<jiangxin@ossxp .co 

i 


[README 
9 Msrdonhelloh 





图 11-18 qgit 中 显示 的 最 新 提交 


11.4 命令 行 工 具 


LT 


上 面 介 绍 的 几 款 图 形 界面 的 Git 版 本 库 浏览 器 最 大 的 特色 就 是 更 好 
看 的 提交 关系 图 ， 还 能 非常 方便 地 浏览 历史 提交 的 目录 树 ， 并 从 历史 提 
交 的 目录 树 中 提取 文件 等 。 这 些 操作 对 于 Git 命 令 行 同样 可 以 完成 。 使 
用 Git 命 令 行 探 索 版 本 库 历史 对 于 您 来 说 并 不 新 鲜 ， 因 为 在 前 几 章 的 实 
践 中 已 经 用 到 了 相关 命令 ， 展 示 了 对 历史 记录 的 操作 。 本 节 将 对 这 些 命 
令 的 部 分 要 点 进行 强调 和 补充 。 





前 面 历次 实践 的 提交 基本 上 是 线性 的 提交 ， 研 究 起 来 没有 挑战 性 。 
为 了 能 够 更 加 接近 于 实际 叉 不 失 简 洁 ， 我 构造 了 一 个 版 本 库 放 在 了 
Github 上 。 可 以 通过 如 下 操作 在 本 地 克隆 这 个 示例 版 本 库 。 





$ cd /path/to/my/workspace/ 

$ git clone git://github.com/ossxp-com/gitdemo-commit-tree.git 
Cloning into gitdemo-commit-tree... 

remote: Counting objects: 63, done. 

remote: Compressing objects: 100% (51/51), done. 

remote: Total 63 (delta 8), reused 0 (delta 0) 

Receiving objects: 100% (63/63), 65.95 KiB, done. 

Resolving deltas: 100% (8/8), done. 

$ cd gitdemo-commit-tree 





运行 gitg 命 令 ， 显 示 其 提交 关系 图 ， 如 图 11-19 所 示 。 





Subject |Author |pate | 
| | 
Add Images for git treeview，jiang Xin 2010 年 12 月 09 日 星期 四 


四 commit A: merge B with C. jiang Xin 2010 年 12 月 09 日 星期 四 









commit C. Jiang Xin 2010 年 12 月 09 日 星期 四 
Commit B: merge D with E and F jiang Xin 2010 年 12 月 09 日 星期 四 


上 日 commit F: merge | with J jiang Xin 2010 年 12 月 09 日 星期 四 
Oo) commit D: merge G with H jiang Xin 2010 年 12 月 09 日 星期 四 





四 commit' jiang Xin 2010 年 12 月 09 日 星期 四 

© 0 commit |. jiang Xin 2010 年 12 月 09 日 星期 四 
© commit E. jiang Xin 2010 年 12 月 09 日 星期 四 | 
commit H. jiang Xin 2010 年 12 月 09 日 星期 四 | 

©® [G6| commit G. jiang Xin 2010 年 12 月 09 日 星期 四 


图 11-19 演示 版 本 库 的 提交 分 支 图 


是 不 是 有 点 “ 乱 花 渐 欲 迷人 眼 ” 的 感觉 。 如 果 把 提交 用 里 程 碑 标识 的 
圆圈 来 代表 ， 稍 加 排列 束 会 看 到 下 面 的 更 为 直 白 的 提交 关系 图 ， 如 图 
11-20 所 示 。 





图 11-20 简化 的 提交 分 支 图 


Git 的 大 部 分 命令 可 以 使 用 提交 版 本 作为 参数 〈 如 : git diff<commit- 
id>) ， 有 的 命令 则 使 用 一 个 版 本 范围 作为 参数 〈 如 : git log<rev1>.. 
<rev2>) 。Git 的 提交 有 着 各 式 各 样 的 表示 法 ， 提 交 范 围 也 是 一 样 ， 下 面 
就 通过 两 个 命令 git rev-parse 和 git rev-list 分 别 研究 一 下 Git 的 版 本 表示 法 
和 版 本 范围 表示 法 。 


11.4.1 版 本 表示 法 : git rev-parse 


命令 git rev-parse 是 Git 的 一 个 底层 命令 ， 其 功能 非常 丰富 〈 或 者 说 
杂乱 ) ， 很 多 Git 脚 本 或 工具 都 会 用 到 这 条 命令 


此 命令 的 部 分 应 用 在 “第 4 章 Git 初 始 化 ”一 章 中 就 已 经 看 到 。 例 如 可 
以 显示 Git 版 本 库 的 位 置 (--git-dir〉， 当 前 工作 区 目录 的 深度 (--show- 
cdup) ， 甚 至 可 以 被 Git 无 关 的 应 用 用 于 解析 命令 行 参数 〈-- 


parseopt) 。 








此 命令 可 以 显示 当前 版 本 库 中 的 引用 。 





$ git rev-parse --symbolic --branches 
master 





" 显示 里 程 碑 。 





git rev-parse --symbolic --tags 


$ 
A 
B 
C 
D 
E 
F 
G 
H 
I 
J 





` 显示 定义 的 所 有 引用 。 


其 中 refs/remotes/ 目 录 下 的 引用 称 为 远程 分 支 〈 或 远程 引用 ) ， 在 





$ git rev-parse --symbolic --glob=refs/* 
refs/heads/master 
refs/remotes/origin/HEAD 
refs/remotes/origin/master 
refs/tags/A 

refs/tags/B 

refs/tags/CcC 

refs/tags/D 

refs/tags/E 

refs/tags/F 

refs/tags/6 

refs/tags/H 

refs/tags/I 

refs/tags/J 





命令 git rev-parse 的 另外 一 个 重要 功能 就 是 将 一 个 Git 对 象 表达 式 表 
示 为 对 应 的 SHA1 哈 希 值 。 针 对 本 节 开 始 克 隆 的 厂 本 库 gitdemo-commit- 
tree， 做 如 下 操作 。 


(1) 显示 HEAD 对 应 的 SHA1 哈 希 值 。 





$ git rev-parse HEAD 
6652aQdce6a5067732c00ef0a220810a7230655e 





(2) 命令 git describe 的 输出 也 可 以 解析 为 正确 的 SHA1 哈 希 值 。 





$ git describe 

A-1-g6652a0d 

$ git rev-parse A-1-g6652a0d 
6652a0dce6a5067732c00ef0a220810a7230655e 








(3) 可 以 同时 显示 多 个 表达 式 的 SHA1 哈 希 值 。 


下 面 的 操作 可 以 看 出 master 和 refs/heads/master 都 可 以 用 于 指 代 


master 分 支 。 





$ git rev-parse master refs/heads/master 
6652a0dce6a5067732c0gef0a220810a7230655e 
6652a0dce6a5067732c0gef0a220810a7230655e 





(4) 可 以 用 哈 希 值 的 前 几 位 指 代 整 个 哈 希 值 。 





$ git rev-parse 6652 6652a0d 
6652a0dce6a5067732c00ef0a220810a7230655e 
6652a0dce6a5067732c00ef0a220810a7230655e 











(5) 里 程 碑 的 两 种 表示 法 均 指 向 相同 的 对 象 。 





$ git rev-parse A refs/tags/A 
c9b03a208288aebdbfe8d84aeb984952a16da3f2 
c9b03a208288aebdbfe8d84aeb984952a16da3f2 





(6) 里 程 碑 A 实际 指向 的 是 一 个 Tag 对 象 而 非 提交 ， 用 下 面 的 三 个 
表示 法 可 以 显示 提交 本 里 的 哈 希 值 而 非 里 程 碑 对 象 的 哈 希 值 。 








还 有 ， 下 面 的 语法 也 可 以 直接 作用 于 轻 量 级 里 程 碑 (直接 指 问 提 交 
的 里 程 碑 ) ， 或 者 作用 于 提交 本 号 。 





$ git rev-parse A^{} A^0 A^{commit} 

81993234fc12a325d303eccea20f6fd629412712 
81993234fc12a325d303eccea20f6fd629412712 
81993234fc12a325d303eccea20f6fd629412712 





(7) A 的 第 一 个 父 提 交 束 是 B 所 指 癌 的 所 交 。 


回忆 之 前 的 介绍 ，“^” 操 作 符 代表 父 提交 。 当 一 个 提交 有 多 个 父 提 
交 时 ， 可 以 通过 在 符号 “后 面 跟 上 一 个 数字 表示 第 几 个 父 提 
交 。“A 人 ”就 相当 于 “A^1”。 而 BA0 代 表 了 B 所 指向 的 一 个 Commit 对 和 象 
(因为 B 是 Tag 对 象 ) 。 








$ git rev-parse A^ A^1 BA9 

776c5c9da9dcbb7e463c061d965ea47e73853b6e 
776c5c9da9dcbb7e463c061d965ea47e73853b6e 
776c5c9da9dcbb7e463c061d965ea47e73853b6e 





(8) 更 为 复杂 的 表示 法 。 





连续 的 “^” 符 号 依次 沿 看 父 提交 进行 定位 至 条 一 祖先 提交 。“^* 后 面 


的 数字 代表 该 提交 的 第 几 个 父 提 区 。 





$ git rev-parse AAA3A2 FA2 J 人 ^{} 

3252fcce40949a4a622a1ac012cb120d6b340ac8 
3252fcce40949a4a622a1ac012cb120d6b340ac8 
3252fcce40949a4a622a1ac012cb120d6b340ac8 





(9) 记号 ~<n> 就 相当 于 连续 <n> 个 符 写 “人 。 





$ git rev-parse A~3 A^^ GA^0 

e80aa7481beda65ae00e35afc4bc4b171f9boebf 
e80aa7481beda65ae00e35afc4bc4b171f9boebf 
e80aa7481beda65ae00e35afc4bc4b171f9boebf 





(10) 显示 里 程 碑 A 对 应 的 目录 树 。 下 面 两 种 写法 都 可 以 。 





$ git rev-parse A^{tree} A: 
95ab9e7db1i4ca113d5548dc20a4872950e8e08c0 
95ab9e7db14ca113d5548dc20a4872950e8e08c0 








(11) 显示 树 里 面 的 文件 ， 下 面 两 种 表示 法 均 可 。 





$ git rev-parse A^{tree}:src/Makefile A:src/Makefile 
96554c5d4590dbde28183e9a6a3199d526eeb925 
96554c5d4590dbde28183e9a6a3199d526eeb925 





(12) 和 暂 存 区 里 的 文件 和 HEAD 中 的 文件 相同 。 





$ git rev-parse :gitg.png HEAD:gitg.png 
fc58966cccie5af24c2c9746196550241bc01c50 
fc58966cccie5af24c2c9746196550241bc01c50 








(13) 还 可 以 通过 在 提交 日 志 中 查找 字 串 的 方式 显示 提交 。 





$ git rev-parse :/"Commit A" 
81993234fc1i2a325d303eccea20f6fd629412712 











(14) 再 有 就 是 reflog 相 关 的 语法 ， 参 见 “ 第 7 章 Git 重 置 " 一 章 中 关于 


reflog 的 介绍 。 





$ git rev-parse HEAD@{0} master@{0} 
6652a0dce6a5067732c0gef0a220810a7230655e 
6652a0dce6a5067732c0gef0a220810a7230655e 





11.4.2 版 本 范围 表示 法 : git rev-list 


有 的 Git 命 令 使 用 一 个 版 本 范围 作为 参数 ， 命 令 git rev-list 可 以 帮助 
研究 Git 的 各 种 版 本 范围 的 语法 。 





8199323 


e800aa7d 2abs2ad 634836Cc 32952fcc 


图 11-21 标记 了 提交 ID 的 分 支 图 


. 如 图 11-21 所 示 ， 一 个 提交 ID 实际 上 就 可 以 代表 一 个 版 本 列表 ， 
含义 是 该 版 本 开始 的 所 有 历史 提交 。 





$ git rev-list --oneline A 

8199323 Commit A: merge B with C， 
ocd7f2e commit C. 

776c5c9 Commit B: merge D with E and F 
beb30ca Commit F: merge I with J 
212efce Commit D: merge G with H 
634836c commit I. 
3252fcc commit J. 
83be369 commit E 
2ab52ad commit H 
e80aa74 commit G 


| 


“ 两 个 或 多 个 版 本 ， 相 当 于 每 个 版 本 单独 使 用 时 指 代 的 列表 的 并 





$ git rev-list --oneline D F 

beb30ca Commit F: merge I with J 
212efce Commit D: merge G with H 
634836c commit 
3252fcc commit 
2ab52ad commit 
e80aa74 commit 


GY C4 4 





在 一 个 版 本 前 面 加 上 符号 (^) 含义 是 取 反 ， 即 排除 这 个 版 本 及 
其 历史 版 本 。 





$ git rev-list --oneline ^GD 
212efce Commit D: merge G with H 
2ab52ad commit H. 





. 和 上 面 等 价 的 “点 点 ”表示 法 。 使 用 两 个 点 连接 两 个 版 本 ， 如 
G.D， 就 相当 于 ^G D。 





$ git rev-list --oneline G..D 
212efce Commit D: merge G with H 
2ab52ad commit H. 





. 版 本 取 反 ， 参 数 的 顺序 不 重要 , 但 是 “点 点 ”表示 法 前 后 的 版 本 
顺序 很 重要 。 


` 语法: ^BC 





$ git rev-list --oneline 人 ^BC 
ocd7f2e commit C. 





语法: C^B 





$ git rev-list --oneline C A^AB 
ocd7f2e commit C. 





. 语法 : B..C 相 当 于 ^B C 





$ git rev-list --oneline B..C 
ocd7f2e commit C. 





. 语法 : C..B 相 当 于 ^CB 





$ git rev-list --oneline C..B 

776c5c9 Commit B: merge D with E and F 
212efce Commit D: merge G with H 
83be369 commit E. 

2ab52ad commit H. 

e80aa74 commit G 





` 三 点 表示 法 的 含义 是 两 个 版 本 共同 能 够 访问 到 的 除外 。 如 B...C 将 


B 和 C 共 同 能 够 访问 到 的 F、I、J 排 除 在 外 。 





$ git rev-list --oneline B...C 
ocd7f2e commit C. 

776c5c9 Commit B: merge D with E and F 
212efce Commit merge G with H 
83be369 commit 
2ab52ad commit 
e80aa74 commit 


OA 工 mD 





` 三 点 表示 法 ， 两 个 版 本 的 前 后 顺序 没有 关系 。 实 际 上 r1...t2 相 当 
于 rf1r2--not$ (git merge-base--all flt2) ， 所 以 和 顺序 无 关 。 





$ git rev-list --oneline C...B 


gocd7f2e commit C. 

776c5c9 Commit B: merge D with E and F 
212efce Commit D: merge G with H 
83be369 commit 
2ab52ad commit 
e80aa74 commit 


(| 





` 茶 提 交 的 历史 提交 ， 自 身 除 外 ， 用 语法 t1^@ 表 示 。 





$ git rev-list --oneline B^@ 

beb30ca Commit F: merge I with J 
212efce Commit D: merge G with H 
634836c commit 
3252fcc commit 
83be369 commit 
2ab52ad commit 
e80aa74 commit 


OT MG H 





* 提交 本 身 不 包括 其 历史 提交 ， 用 语法 tr1^! 表示 。 





$ git rev-list --oneline BA 人! 

776c5c9 Commit B: merge D with E and F 
$ git rev-list --oneline F^! D 
beb30ca Commit F: merge I with J 
212efce Commit D: merge G with H 
2ab52ad commit H. 





11.4.3 ”浏览 日 志 : git log 


命令 git log 是 老 朋 友 了 ， 在 前 面 的 章节 中 曾经 大 量 地 出 现 ， 用 于 显 
未 提交 历史 。 





命令 git log 的 后 面 可 以 接 表 示 版 本 范围 的 参数 ， 当 不 使 用 任何 表示 


版 本 范围 的 参数 时 ， 相 当 于 使 用 了 默认 的 参数 HEAD， 即 显示 当前 
HEAD 能 够 访问 到 的 所 有 历史 提交 。 下 面 的 示例 使 用 了 前 面 介绍 的 版 本 
范围 表示 法 : 





$ git 1og --oneline F^! D 
beb30ca Commit F: merge I with J 
212efce Commit D: merge G with H 
2ab52ad commit H. 

e80aa74 commit 6G. 





2. 分 文 图 显示 


习 


通过 --graph 参 数 调 用 git log 可 以 显示 字符 界面 的 提交 关系 图 ， 而 且 
不 同 的 分 支 还 可 以 用 不 同 的 颜色 来 表示 。 如 果 希 望 每 次 查看 日 志 的 时 候 
都 看 到 提交 关系 图 ， 可 以 设置 一 个 别名 ， 用 别名 来 调用 。 








$ git config --global alias.glog "1og --graph" 








定义 别名 之 后 ， 每 次 希望 目 动 显示 提交 关系 图 ， 就 可 以 使 用 别名 命 





$ git glog --oneline 
* 6652a0d Add Images for git treeview. 
8199323 Commit A: merge B with C， 
\ 
* Ocd7f2e commit C. 
| 


| 
让 beb30ca Commit F: merge I with J 
| 
| 


* 3252fcc commit J. 
* 634836c commit 工 ， 


* 
| 
| 
| 
| 
*-,  \ 776c5c9 Commit B: merge D with E and F 
| 
| 
| 
| 
| 
| 
| 83be369 commit E， 


六 212efce Commit D: merge G with H 
|\ 

| * 2ab52ad commit H. 

* e80aa74 commit 6G. 





3. 显 显示 最 过 近 的 几 条 日 二 


en 


Wp 


可 以 使 用 参数 -<n> 〈<n> 为 数字 ) ， 显 示 最 近 的 <n> 条 日 志 。 例 如 
下 面 的 命令 显示 最 近 的 3 条 El 





$ git 1og -3 --pretty=oneline 
6652a0dce6a5067732c0g0ef0a220810a7230655e Add Images for git treeview. 
81993234fc12a325d303eccea20f6fd629412712 Commit A: merge B with C. 
ocd7f2ea245d90d414e502467ac749f36aa32cc4 commit C. 











每 次 提交 的 具体 改动 


sx 
却 

习 
| 








使 用 参数 -p 可 以 在 显示 日 志 的 时 候 同 时 显示 改动 。 





$ git 1og -p -1 
commit 6652aQdce6a5067732c00ef0a220810a7230655e 
Author: Jiang Xin <jiangxin@ossxp.com> 
Date: Thu Dec 9 16:07:11 2010 +0800 
Add Images for git treeview. 
Signed-off-by: Jiang Xin <jiangxin@ossxp.com> 
diff --git a/gitg.png b/gitg.png 
new file mode 100644 
index 0000000. .fc58966 
Binary files /dev/null and b/gitg.png differ 
diff --git a/treeview.png b/treeview.png 
new file mode 100644 
index 0000000. .a756d12 
Binary files /dev/null and b/treeview.png differ 





因为 是 二 进 制 文件 改动 ， 默 认 不 显示 改动 的 内 容 。 实 际 上 Git 的 关 
异 文件 提供 对 二 进 制 文件 的 支持 ， 本 书 第 7 篇 第 38 章 将 予以 专题 介 








5. 显 示 每 次 提交 的 变更 概要 








使 用 -p 参 数 会 让 日 志 输 出 显得 非常 元 余 ， 当 不 需要 知道 具体 的 改动 
而 只 想 知 道 改 动 在 哪些 文件 上 时 ， 可 以 使 用 --stat 参 数 。 输 出 的 变更 概要 
像 极 了 GNU 的 diffstat 命 令 的 输出 。 





$ git 1og --stat --oneline I..C 
ocd7f2e commit C. 
README | 
doc/C.txt | 
2 files changed, 2 insertions(+), 0 deletions(-) 
beb30ca Commit F: merge I with J 
3252fcc commit J. 


国富 
型 和 


src/main.c 工 9 十 十 十 十 十 十 十 十 十 十 
src/version.h.in 6 十 十 十 十 十 十 
6 files changed, 54 insertions(+), 0 deletions(-) 


README | 了 十 十 十 十 十 十 十 

doc/J.txt | 下 全 

src/.gitignore | 3 +++ 

src/Makefile | 27 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 
| 
| 





6. 定 制 输出 





Git 的 日 志 输 出 命令 提供 了 很 多 输出 模板 选择 ， 可 以 根据 需要 选择 
见 余 显示 或 精简 显示 。 





参数 --pretty=raw 显 示 commit 的 原始 数据 ， 可 以 显示 提交 对 应 的 树 
ID。 





$ git 10og --pretty=raw -1 

commit 6652aQdce6a5067732c00ef0a220810a7230655e 

tree e33be9e8e7ca5f887c7d5601054f2f510e6744b8 

parent 81993234fc12a325d303eccea20f6fd629412712 

author Jiang Xin <jiangxin@ossxp.com> 1291882031 +0800 

committer Jiang Xin <jiangxin@ossxp.com> 1291882892 +0800 
Add Images for git treeview. 
Signed-off-by: Jiang Xin <jiangxin@ossxp.com> 


il 





参数 --pretty=fuller 会 同时 显示 作者 和 提交 者 ， 两 者 可 以 不 同 。 





$ git 1og --pretty=fuller -1 
commit 6652a0dce6a5067732c0oef0a220810a7230655e 


Author: Jiang Xin <jiangxin@ossxp.com> 
AuthorDate: Thu Dec 9 16:07:11 2010 +0800 
Commit: Jiang Xin <jiangxin@ossxp.com> 


CommitDate: Thu Dec 9 16:21:32 2010 +0800 
Add Images for git treeview. 
Signed-off-by: Jiang Xin <jiangxin@ossxp.com> 





参数 --pretty=oneline 显 然 会 提供 最 精简 的 日 志 输 出 。 也 可 以 使 用 -- 
oneline 参 数 ， 效 果 近 似 。 





$ git 10og --pretty=oneline -1 
6652a0dce6a5067732c00ef0a220810a7230655e Add Images for git treeview. 





如 果 只 想 查 看 和 分 析 茶 一 个 提交 ， 也 可 以 使 用 git show 或 git cat-file 


命令 。 使 用 git show 显 示 里 程 碑 D 及 其 提交 : 


五 





$ git Show D --Stat 
tag D 
Tagger: Jiang Xin <jiangxin@ossxp.com> 
Date: Thu Dec 9 14:24:52 2010 +0800 
create node D 
commit 212efce1548795a1ledb08e3708a50989fcd73cce 
Merge: e80aa74 2ab52ad 
Author: Jiang Xin <jiangxin@ossxp.com> 
Date: Thu Dec 9 14:06:34 2010 +0800 
Commit D: merge G with H 
Signed-off-by: Jiang Xin <jiangxin@ossxp.com> 


README | 2 ++ 
doc/D.txt | 1+ 
doc/H.txt | 于 7 


3 files changed， 4 insertions(+), 0 deletions(-) 





使 用 git cat-file 显 示 里 程 碑 D 及 其 提交。 参数 -p 的 含义 是 美观 的 输出 


(pretty) 。 


| 


$ git cat-file -p DA0 

tree 1c22e90c6bf1i50ee1icde6cefb476abbb921f491f 

parent e80aa7481beda65ae00e35afc4bc4b171f9boebf 

parent 2ab52ad2a30570109e71b56fa1780f0442059b3c 

author Jiang Xin <jiangxin@ossxp.com> 1291874794 +0800 
committer Jiang Xin <jiangxin@ossxp.com> 1291875877 +0800 
Commit D: merge G with H 

Signed-off-by: Jiang Xin <jiangxin@ossxp.com> 





11.4.4 ”差异 比较 : git diff 


Git 差 异 比 较 功能 在 前 面 的 实践 中 也 反复 地 接触 过 了 ， 尤 其 是 在 介 
绍 暂 存 区 的 相关 音节 重点 介绍 了 git diff 命 令 如 何 对 工作 区 、 暂 存 区 、 版 
本 库 进行 比较 : 





" 比较 里 程 碑 B 和 里 程 碑 A， 用 命令 : git diffB A 

* 比较 工作 区 和 里 程 碑 和 A， 用 命令 : git diff A 

. 比较 暂 存 区 和 里 程 碑 A， 用 命令 : git diff--cached A 
" 比较 工作 区 和 和 暂 存 区 ， 用 命令 : git diff 

` 比较 暂 存 区 和 HEAD， 用 命令 : git diff--cached 

` 比较 工作 区 和 HEAD， 用 命令 : git diff HEAD 
1. 文 件 不 同 版 本 的 差异 比较 


差异 比较 还 可 以 使 用 路 径 参 数 ， 只 显示 不 同 版 本 间 该 路 径 下 文件 的 


差异 。 语 法 格式 如 下 : 





$ git diff <commit1> <commit2> -- <paths> 





2. 非 Git 目 录 / 文 件 的 差异 比较 


命令 git diff 还 可 以 在 Git 版 本 库 之 外 执行 ， 对 非 Git 目 录 进 行 比较 ， 
就 像 GNU 的 diff 命 令 一 样 。 之 所 以 提供 这 个 功能 是 因为 Git 差 寞 比较 命令 
更 为 强大 ， 提 供 了 对 二 进 制 文件 差异 等 的 扩展 支持 。 语 法 格式 如 下 : 





$ git diff <path1> <path2> 





3. 扩 展 的 差异 语法 





Git 扩 展 了 GNU 的 差异 比较 语法 ， 提 供 了 对 重 命名 、 二 进 制 文件 、 
文件 权限 变更 的 文 持 。 本 书 第 7 篇 第 38 章 将 专题 介绍 。 





4. 逐 词 比较 ， 而 非 默认 的 逐 行 比较 


Git 的 差异 比较 默认 是 逐 行 比较 ， 分 别 显示 改动 前 的 行 和 改动 后 的 
行 ， 到 底 改 动 在 哪里 还 需要 仔细 辨别 。Git 还 提供 一 种 逐 词 比较 的 输 
出 ， 有 的 人 会 更 喜欢 。 使 用 --word-diff 参 数 可 以 显示 逐 词 比 较 。 








$ git diff --word-diff 
diff --git a/src/book/02-use-git/080-git-history-travel.rst b/src/book/02-use-git/0Qt 
index f740203. .2dd3e6f 100644 
-- a/src/book/02-use-git/080-git-history-travel.rst 
+++ b/src/book/02-use-git/080-git-history-travel.rst 
@@ -681，7 +681，7 @@ Git 的 大 部 分 命令 可 以 使 用 提交 版 本 作为 参数 如: git diff) ， 




















[-18:23:48 jiangxin@hp:~/gitwork/gitbook/src/book$-]{+$+} git 1og --stat --oneline 
Qcd7f2e commit C. 
README | 


工 十 
doc/C.txt | 1 + 

















上 面 的 逐 词 差异 显示 是 有 颜色 的 : 删除 内 容 [-.…-] 用 红色 表示 ， 添 加 
的 内 容 {+...+} 用 绿色 表示 。 


11.4.5 文件 追溯 : git blame 





在 软件 开发 过 程 中 当 发 现 Bug 并 定位 到 具体 的 代码 时 ，Git 的 文件 追 
漳 命 令 可 以 指出 是 谁 在 什么 时 候 ， 以 及 什么 版 本 引入 的 此 Bug。 


当 针 对 文件 执行 git blame 命 令 时 ， 融 会 逐 行 显示 文件 ， 在 每 一 行 的 
行 首 显示 此 行 最 早 是 在 什么 版 本 引入 的 ， 由 谁 引 入 的 。 











$ cd /path/to/my/workspace/gitdemo-commit-tree 
$ git blame README 

^e80aa74 (Jiang Xin 2010-12-09 14:00:33 +0800 1) DEMO program for git-scm-book. 
^e80aa74 (Jiang Xin 2010-12-09 14:00:33 +0800 2) 

^e80aa74 (Jiang Xin 2010-12-09 14:00:33 +0800 3) Changes 

^e80aa74 (Jiang Xin 2010-12-09 14:00:33 +0800 4) ======= 

^e80aa74 (Jiang Xin 2010-12-09 14:00:33 +0800 5) 
81993234 (Jiang Xin 2010-12-09 14:30:15 +0800 6) 
Ocd7f2ea (Jiang Xin 2010-12-09 14:29:09 +0800 7) 
776c5c9d (Jiang Xin 2010-12-09 14:27:31 +0800 8) 
beb30ca7 (Jiang Xin 2010-12-09 14:11:01 +0800 9) create node 
^3252fcc (Jiang Xin 2010-12-09 14:00:33 +0800 10) create node 


* create node 
* 
* 
党 
* 
和 634836c (Jiang Xin 2010-12-09 14:00:33 +0800 11) * create node 
* 
* 
* 
* 
* 


create node 
create node 


^83be369 (Jiang Xin 2010-12-09 14:00:33 +0800 12) create node 
212efce1 (Jiang Xin 2010-12-09 14:06:34 +0800 13) create node 
^2ab52ad (Jiang Xin 2010-12-09 14:00:33 +0800 14) create node 
^e80aa74 (Jiang Xin 2010-12-09 14:00:33 +0800 15) create node 
^e80aa74 (Jiang Xin 2010-12-09 14:00:33 +0800 16) initialized. 


MOAIIOMHOTHWOPD 





只 想 查 看 某 几 行 ， 使 用 -L n，m 参 数 ， 合 令 如 下 : 





$ git blame -L 6, +5 README 

81993234 (Jiang Xin 2010-12-09 14:30:15 +0800 6) * create node A， 
Ocd7f2ea (Jiang Xin 2010-12-09 14:29:09 +0800 7) * create node C， 
776c5c9d (Jiang Xin 2010-12-09 14:27:31 +0800 8) * create node B. 
beb30ca7 (Jiang Xin 2010-12-09 14:11:01 +0800 9) * create node F. 
^3252fcc (Jiang Xin 2010-12-09 14:00:33 +0800 10) * create node J. 





11.4.6 ”二 分 查找 : git bisect 





前 面 的 文件 追溯 是 建立 在 问题 (Bug) 已 经 定位 《到 代码 上 ) 的 基 
础 之 上 ， 然 后 才能 通过 错误 的 行 〈 代 码 ) 找到 人 《提交 者 ) ， 打 板子 
(教育 或 惩 昼 ) 。 那 么 如 何 定位 问题 呢 ? Git 的 二 分 查找 命令 可 以 提供 
帮助 。 


二 分 查找 并 不 神秘 ， 也 不 是 万 灵 药 ， 是 建立 在 测试 的 基础 之 上 的 。 
实际 上 很 多 做 过 软件 测试 的 人 部 可 能 使 用 过 : “最 新 的 版 本 出 现 Bug 了， 
但 是 在 给 茶 客 户 的 版 本 却 没有 这 个 问题 ， 所 以 问题 肯定 出 在 两 者 之 间 的 
某 次 代码 提交 上 ”。 








1. 使 用 二 分 查找 





Git 提 供 的 git bisect 命 令 是 基于 版 本 库 的 、 目 动 化 的 问题 得 找 和 定位 
工具 ， 取 代 传 统 软 件 测试 中 针对 软件 及 布 版 本 的 、 无 法 定位 到 代码 的 、 
粗放 式 的 测试 方法 。 


执行 二 分 查找 ， 在 发 现 问题 后 ， 首 先 要 找到 一 个 正确 的 版 本 ， 如 果 
所 发 现 的 问题 从 软件 最 早 的 版 本 惑 是 错 的 ， 那 么 就 没有 必要 执行 二 分 碍 


找 了 ， 还 是 老 老实 实 的 Debug 吧 。 但 是 如 果 能 够 找到 一 个 正确 的 版 本 ， 
即 在 这 个 正确 的 版 本 上 问题 没有 发 生 ， 那 么 就 可 以 开始 使 用 git bisect 命 
令 在 版 本 库 中 进行 二 分 查找 了 : 


(1) 工作 区 切换 到 已 知 的 “好 版 本 * 和 “ 坏 版 本 ”的 中 间 的 一 个 版 





(2) 执行 测试 ， 如 果 问 题 重 现 ， 则 将 版 本 库 当 前 版 本 库 标 记 为 “ 坏 
版 本 >”， 如 果 问 题 没 有 重 现 ， 则 将 当前 版 本 标记 为 “好 版 本 ”。 


(3) 重复 1-2， 直 至 最 终 找 到 第 一 个 导致 问题 出 现 的 版 本 。 





图 11-22 是 示例 版 本 库 标记 了 提交 ID 后 的 示意 图 ， 在 这 个 示例 版 本 
库 中 试验 二 分 碍 找 流 程 : 首先 标记 最 新 提交 (HEAD) 是 “ 坏 的 ”，G 提 
交 是 好 的 ， 然 后 通过 奉 找 最 终 定 位 到 坏 提 交 〈B) 。 





6652a0d 


A ) 8199323 







776C5C9 Ocd7f2e 





212efce NE beb36ca 


83be369 A ™ 
(H) (I) (2) 
e86aa74 ”2ab52ad 634836c 3252fcc 


图 11-22” 二 分 法 寻找 坏 提交 


在 下 面 的 试验 中 定义 坏 提交 的 依据 很 简单 ， 如 果 在 doc 目 录 中 包含 
文件 B.txt， 则 此 版 本 是 “ 坏 ” 的 。 (这 个 示例 太 简 陋 ， 不 要 见笑 ， 聪 明 的 
读者 可 以 直接 通过 doc/B.txt 文 件 就 可 追溯 到 B 提 交 


下 面 开 始 通 过 手动 测试 (查找 doc/B.txt 存 在 与 否 )， 借 助 Git 二 分 查 
找 定位 “问题 ?版 本 ， 有 具体 操作 步骤 如 下 。 


(1) 首先 确认 工作 在 master 分 支 。 





$ cd /path/to/my/workspace/gitdemo-commit-tree/ 
$ git checkout master 
Already on 'master' 





(2) 开始 二 分 碍 找 。 





$ git bisect start 





(3) 当前 版 本 已 经 是 “ 坏 提 交 ”， 因 为 存在 文件 dowB.txt。 而 G 版 本 
是 “好 提交 ”， 因 为 不 存在 文件 docB.txt。 








$ git cat-file -t master:doc/B.txt 

blob 

$ git cat-file -t G:doc/B.txt 

fatal: Not a Valid object name G:doc/B.txt 





(4) 将 当前 版 本 HEAD) 标记 为 “ 坏 提交 ”， 将 G 版 本 标记 为 “好 


提交 ”。 





$ git bisect bad 

$ git bisect good G 

Bisecting: 5 revisions left to test after this (roughly 2 steps) 
[Ocd7f2ea245d90d414e502467ac749f36aa32cc4] commit C. 





(5) 目 动 定位 到 C 提 交 。 没 有 文件 doc/B.txt， 也 是 一 个 好 提交 。 





$ git describe 

CC 

$ ls doc/B.txt 

ls: 无 法 访问 doc/B.txt: 没有 那个 文件 或 目录 






































(6) 标记 当前 版 本 C 提 交 ) 为 “好 提交 ”。 





$ git bisect good 
Bisecting: 3 revisions left to test after this (roughly 2 steps) 
[212efce1548795aiedb08e3708a50989fcd73cce] Commit D: merge G with H 





(7) 现在 定位 到 D 版 本 ， 这 也 是 一 个 “好 提交 ”。 





$ git describe 

D 

$ 1s doc/B.txt 

ls: 无 法 访问 doc/B.txt: 没有 那个 文件 或 目录 






































(8) 标记 当前 版 本 (CD 提交 ) 为 “好 提交 ”。 





$ git bisect good 
Bisecting: 1 revision left to test after this (roughly 1 step) 
[776c5c9da9dcbb7e463c061d965ea47e73853b6e] Commit B: merge D with E and F 





(9) 现在 定位 到 B 版 本 ， 这 是 一 个 “ 坏 提 交 ”。 





$ git bisect bad 
Bisecting: © revisions left to test after this (roughly 0 steps) 
[83be36956c007d7bfffe13805dd2081839fd3603] commit E. 





(10) 现在 定位 到 E 版 本 ， 这 是 一 个 “好 提交 ”。 当 标记 E 为 好 提交 之 
后 ， 输 出 显示 已 经 成 功 定位 到 引入 坏 提交 的 最 接近 的 版 本 。 





$ git bisect good 
776c5c9da9dcbb7e463c061d965ea47e73853b6e jis the first bad commit 





(11) 最 终 定位 的 坏 提 交 用 引用 refs/bisect/bad 标 识 。 可 以 用 如 下 方 
法 切换 到 该 版 本 。 





$ git checkout bisect/bad 
Previous HEAD position was 83be369... commit E. 
HEAD is now at 776c5c9,... Commit B: merge D with E and F 





《12) 当 对 “Bug” 定 位 和 修复 后 ， 撤 销 二 分 碍 找 在 版 本 库 中 遗留 的 
临时 文件 和 引用 。 


撤销 二 分 得 找 后 ， 版 本 库 切 换 回 执行 二 分 得 找 之 前 所 在 的 分 文 。 





$ git bisect reset 
Previous HEAD position was 776c5c9,,，Commit B: merge D with E and F 
Switched to branch "master 








2. 把 “好 提交 ”标记 成 了 “ 坏 提交 ”该 怎么 办 ? 


在 执行 二 分 查找 的 过 程 中 ， 一 不 小 心 就 有 可 能 犯错 ， 将 “好 提交 ” 标 
记 为 “ 坏 提 交 ”*”， 或 者 相反 。 这 将 导致 前 面 的 伍 找 过 程 也 前 功 尽 弃 。 为 
此 ，Git 的 二 分 查找 提供 了 一 个 恢复 查找 进度 的 办 法 ， 具 体操 作 过 程 如 
Ps 








(1) 例如 对 提交 E， 本 来 是 一 个 “好 版 本 " 却 被 错误 的 标记 为 “ 坏 版 





$ git bisect bad 
83be36956c007d7bfffe13805dd2081839fd3603 is the first bad commit 





(2) 用 git bisect log 命 令 查 看 二 分 查找 的 日 志 记录 。 


把 二 分 查找 的 日 志保 存在 一 个 文件 中 。 





$ git bisect 1og > logfile 





(3) 编辑 这 个 文件 ， 删 除 记 录 了 错误 动作 的 行 。 


以 井 号 〈#) 开始 的 行 是 注释 。 





$ cat logfile 

# bad: [6652a0dce6a5067732c00ef0a220810a7230655e] Add Images for git treeview. 

# good: [e80aa7481beda65ae00e35afc4bc4b171f9boebf] commit 6G. 

git bisect start 'master' 'G' 

# good: [Qcd7f2ea245d90d414e502467ac749f36aa32cc4] commit C. 

git bisect good Ocd7f2ea245d90d414e502467ac749f36aa32cc4 

# good: [212efce1548795aledb08e3708a50989fcd73cce] Commit D: merge G with H 

git bisect good 212efce1548795a1ledb08e3708a50989fcd73cce 

# bad: [776c5c9da9dcbb7e463c061d965ea47e73853b6e] Commit B: merge D with E and F 
git bisect bad 776c5c9da9dcbb7e463c061d965ea47e73853b6e 





(4) 结束 正在 进行 的 出 错 的 二 分 碍 找 。 





$ git bisect reset 
Previous HEAD position was 83be369... commit E. 
Switched to branch 'master' 








(5) 通过 日 志文 件 恢复 进度 ， 重 启 二 分 但 找 。 





$ git bisect replay logfile 

We are not bisecting. 

Bisecting: 5 revisions left to test after this (roughly 2 steps) 
[Ocd7f2ea245d90d414e502467ac749f36aa32cc4] commit C. 

Bisecting: © revisions left to test after this (roughly 0 steps) 
[83be36956c007d7bfffe13805dd2081839fd3603] commit E. 








(6) 再 一 次 回 到 了 提交 E， 这 一 次 不 要 标记 错 了 哦 。 





$ git describe 

E 

$ git bisect good 

776c5c9da9dcbb7e463c061d965ea47e73853b6e is the first bad commit 





3. 二 分 僵 找 使 用 自动 化 测试 


Git 的 二 分 查找 命令 支持 run 子 命令 ， 可 以 运行 一 个 目 动 化 测试 脚 
本 ， 实 现 自动 的 二 分 查找 。 





` 如 果 脚 本 的 退出 码 是 0， 正 在 测试 的 版 本 是 一 个 “好 版 本 ”。 
. 如 果 脚 本 的 退出 码 是 125， 正 在 测试 的 版 本 被 跳 过 。 


. 如 果 脚 本 的 退出 码 是 1 到 127 (125 除 外 ) ， 正 在 测试 的 版 本 是 一 
个 “ 坏 版 本 ” , 





为 本 例 写 一 个 自动 化 测试 太 简 单 了 ， 无 非 就 是 判断 文件 是 否 存在 ， 
存在 则 返回 错误 码 1， 不 存在 则 返回 错误 码 0。 测 试 脚本 good-or-bad.sh 如 
下 : 











#!1/bin/sh 
[ -f doc/B.txt ] && exit 1 
exit 0 





用 此 脚本 实现 目 动 化 二 分 碍 找 的 过 程 非常 简单 ， 具 体操 作 步 又 如 
下 


(1) 从 已 知 的 坏 版 本 master 和 好 版 本 G 开 始 新 一 轮 的 二 分 碍 找 。 





$ git bisect start master G 
Bisecting: 5 revisions left to test after this (roughly 2 steps) 
[ocd7f2ea245d90d414e502467ac749f36aa32cc4] commit C. 





(2) 自动 化 测试 ， 使 用 脚本 good-or-bad.sh。 





$ git bisect run sh good-or-bad.sh 

running sh good-or-bad ,sh 

Bisecting: 3 revisions left to test after this (roughly 2 steps) 
[212efce1548795aiedb08e3708a50989fcd73cce] Commit D: merge G with H 
running sh good-or-bad.sh 

Bisecting: 1 revision left to test after this (roughly 1 step) 
[776c5c9da9dcbb7e463c061d965ea47e73853b6e] Commit B: merge D with E and F 
running sh good-or-bad.sh 

Bisecting: © revisions left to test after this (roughly 9 steps) 
[83be36956c007d7bfffe13805dd2081839fd3603] commit E. 

running sh good-or-bad ,sh 

776c5c9da9dcbb7e463c061d965ea47e73853b6e is the first bad commit 
bisect run success 





(3) 定位 到 的 “ 坏 版 本 ”是 B。 





$ git describe refs/bisect/bad 
B 





11.4.7 获取 历史 版 本 








提取 历史 提交 中 的 文件 无 非 束 是 表 11-1 中 的 操作 ， 在 之 前 的 实践 中 


己 多 次 用 到 ， 这 里 不 再 更 述 


表 11-1 获取 文件 历史 版 本 命令 一 览 表 


动作 命令 格式 示例 


O git ls-tree 776c5c9 README 


查看 历史 提交 的 目录 树 seniorepathe O git ls-tree -r refs/tags/D doc 





整个 工作 区 切换 到 历史 版 本 git checkout <commit> O git checkout HEAD’^ 


O git checkout refs/tags/D 一 README 


检 出 某 文件 的 历史 版 本 git checkout <commit> -- <paths> O git checkout 776c5c9 — doc 


Ogit show 887113d:README > 


检 出 某 文件 的 历史 版 本 到 其 他 文件 名 | git show <commit>:<file> > new_name README OLD 





第 12 章 ”改变 历史 


我 是 电影 《 回 到 未 来 》 的 粉丝 ， 偶 尔 会 做 梦 ， 梦 见 穿梭 到 未 来 拿 回 
一 本 2000-2050 体 育 年 鉴 。 操 作 Git 也 可 以 体验 到 穿梭 时 空 的 感觉 ， 因 为 
Git 像 极 了 一 个 时 光 机 器 ， 不 但 允许 你 在 历史 中 穿梭， 而 且 还 能 够 改变 
历 蝎 ， 


本 章 的 最 开始 将 介绍 两 种 最 简单 和 最 常用 的 历史 变更 操作 一 一 “ 悔 
棋 * 操 作 ， 束 是 对 刚刚 进行 的 一 次 或 几 次 提交 进行 修补 或 撤销 。 对 于 跳 
跃 式 的 历史 记录 的 变更 ， 即 仅 对 过 去 某 一 个 或 茶几 个 提交 做 出 改变 ， 会 
在 “ 回 到 未 来 ”小 市 详细 介绍 。 在 “丢弃 历史 ”小 市 会 介绍 一 种 版 本 库 瘦 映 
的 方法 ， 这 可 能 会 在 东 些 特定 的 场合 用 到 。 








作为 分 布 式 版 本 控制 系统 ， 一 旦 版 本 库 被 多 人 共 译 ， 改 变 历史 就 可 
能 是 无 法 完成 的 任务 。 在 本 章 的 最 后 ， 介 绍 还 原 操 作 以 实现 在 不 改变 历 
史 提 交 的 情况 下 还 原 错误 的 改动 。 








12.1 悔 棋 


在 日 第 的 Git 操 作 中 ， 会 经 常 出 现 这 样 的 状况 ， 输 入 git commit 命 
刚刚 融 下 回 车 键 就 后 悔 了 : 可 能 是 提交 说 明 中 出 现 了 错别字 ， 或 者 有 文 
件 乐 记 提交 ， 或 者 有 的 修改 不 应 该 提交 ， 诸 如 此 类 。 
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像 Subversion 那 样 的 集中 式 厂 本 控制 系统 是 “沙子 无 悔 " 的 系统 ， 
能 叹 一 口气 责怪 自己 太 不 小 心 了 。 然 后 根据 实际 情况 弥补 ， 马上 做 一 次 
新 提交 改正 前 面 的 错误 ; 或 者 只 能 将 错 丈 错 ， 错 误 的 提交 说 明 束 让 它 一 
错 下 去 吧 。 因 为 大 部 分 Subversion 管 理 员 不 敢 或 不 会 放 开 修改 提交 说 
明 的 功能 ， 从 而 导致 无 法 对 提交 说 明 进行 修改 。 














Git 提 供 了“ 悔 棋 * 的 操作 ， 甚 至 因为 “ 单 步 悔 棋 ” 是 如 此 经 常 的 友 生 ， 
访 至 于 Git 提 供 了 一 个 简洁 的 操 


-amend。 








多 补 式 提交 ， 命 令 是 : git commit- 








看 看 当前 版 本 库 最 新 的 两 次 提交 : 





$ cd /path/to/my/workspace/demo 
$ git 1og --stat -2 
commit 822b4aeed5de74f949c9faa5b281001eb5439444 
Author: Jiang Xin <jiangxin@ossxp.com> 
Date: Wed Dec 8 16:27:41 2010 +0800 
测试 使 用 qgit 提交 

README | 1+ 

src/hello.h | 2 - 

2 files changed, 1 insertions(+), 2 deletions(-) 
commit 613486c17842d139871egf1boe9191d2b6177c9f 
Author: Jiang Xin <jiangxin@ossxp.com> 
Date: Tue Dec 7 19:43:39 2010 +0800 






































数 直接 提交 。 




















偷懒 了 ， 直 接 用 -a 
src/hello.h | 1 
1 files changed, 1 insertions(+), 0 deletions(-) 


+ 





最 新 一 次 的 提交 的 确 是 在 上 一 章 使 用 qgit 进 行 的 提交 ， 但 这 和 提交 
内 容 无 关 ， 因 此 需要 改 掉 这 个 提交 的 提交 说 明 。 使 用 下 面 的 命令 即 可 做 
到 。 





$ git commit --amend -m "Remove hello.h, which is useless." 
[master 7857772] Remove hello.h, which is useless ， 

2 files changed， 1 insertions(+), 2 deletions(-) 

delete mode 100644 src/hello.h 





上 和 面 的 命令 使 用 了 -m 参 数 是 为 了 演示 的 方便 ， 实 际 上 完全 可 以 直接 
输入 git commit--amend， 在 弹出 的 提交 说 明 编辑 界面 修改 提交 说 明 ， 然 
后 保存 退出 完成 修补 提交 。 





下 面 再 看 看 最 近 两 次 的 提交 说 明 ， 可 以 看 到 最 新 的 提交 说 明 更 改 了 
(包括 提交 的 SHA1 哈 希 值 ) ， 而 它 的 父 提 交 《 即 前 一 次 提交 ) 没有 改 
2 





$ git 1og --stat -2 
commit 78577724305e3e20aa9f2757ac5531d037d612a6 
Author: Jiang Xin <jiangxin@ossxp.com> 
Date: Wed Dec 8 16:27:41 2010 +0800 
Remove hello.h, which is useless. 

README | 1+ 

src/hello.h | 2 -- 

2 files changed, 1 insertions(+), 2 deletions(-) 
commit 613486c17842d139871e0f1ib0e9191d2b6177c9f 
Author: Jiang Xin <jiangxin@ossxp.com> 
Date: Tue Dec 7 19:43:39 2010 +0800 

偷懒 了 ， 直 接 用 -a 参数 直接 提交 。 
src/hello.h | 1 + 
1 files changed, 1 insertions(+), 0 deletions(-) 






































如 果 最 后 一 步 操作 不 想 删 除 文件 src/hello.h， 而 只 是 想 修 改 
README， 则 可 以 按照 下 面 的 方法 进行 修补 操作 ， 具 体操 作 过 程 如 
下 。 


(1) 还 原 删 除 的 src/hello.h 文 件 。 





$ git checkout HEAD^ -- src/hello.h 





(2) 此 时 查看 状态 ， 会 看 到 src/hello.h 被 重新 添加 回 暂 存 区 。 





$ git status 

# On branch master 

# Changes to be committed: 

(use "git reset HEAD <file>..." to unstage) 


new file: src/hello.h 


亲 半 亲 亲 








(3) 执行 修补 提交 ， 不 过 提交 说 明 是 不 是 也 要 更 改 呢 ， 因 为 毕 葛 
这 次 提交 不 会 删除 文件 了 。 





$ git commit --amend -m "commit with --amend test." 
[master 2b45206] commit with --amend test. 
1 files changed, 1 insertions(+), 0 deletions(-) 





(4) 再 次 查看 最 近 的 两 次 提交 ， 会 发 现 最 新 的 提交 不 再 删除 文件 
src/hello.h 了 。 





$ git 1og --stat -2 
commit 2b452066ef6e92bceb999cf94fcce24afb652259 
Author: Jiang Xin <jiangxin@ossxp.com> 
Date: Wed Dec 8 16:27:41 2010 +0800 
commit with --amend test. 


README | 


1 


+ 


1 files changed, 1 insertions(+), 0 deletions(-) 
commit 613486c17842d139871e0f1ib0e9191d2b6177c9f 
Author: Jiang Xin <jiangxin@ossxp.com> 
Date: Tue Dec 7 19:43:39 2010 +0800 


偷懒 了 ， 


























直接 


src/hello.h | 
1 files changed, 1 insertions(+), 0 deletions(-) 


用 -a 参数 直接 提交 。 








1+ 





12.2 多 步 悔 棋 


Git 能 够 提供 悔 棋 的 奥秘 在 于 Git 的 重 置 命令 。 实 际 上 上 面 介绍 的 单 
步 悔 棋 也 可 以 用 重 置 命令 来 实现 ， 只 不 过 Git 提 供 了 一 个 更 好 用 更 简洁 
的 修补 提交 命令 而 已 。 多 步 悔 棋 顾名思义 就 是 可 以 取消 最 新 连续 的 多 次 
提交 。 多 次 悔 棋 并 非 是 所 有 分 布 式 版 本 控制 系统 都 具有 的 功能 ， 像 
Mercuria/Hg 只 能 对 最 新 提交 悔 棋 一 次 “除非 使 用 MQ 插件 ) 。Git 因 为 
有 了 强大 的 重 置 命令 ， 可 以 任意 悔 棋 多 次 。 




















多 步 悔 棋 会 在 什么 场合 用 到 呢 ? 软件 开发 中 针对 某 个 特性 功能 的 开 
发 就 是 一 例 。 某 个 开发 工程 师 领受 某 个 特性 开发 的 任务 ， 于 是 在 本 地 版 
本 库 进行 了 一 系列 开发 、 测 试 、 修 补 、 再 测试 的 流程 ， 最 终 特性 功能 
发 完毕 后 可 能 在 版 本 库 中 留 下 了 多 次 提交 。 在 将 本 地 版 本 库 改动 推送 
CPUSH) 到 团队 协同 工作 的 核心 版 本 库 时 ， 这 个 开发 人 员 就 想 用 多 步 
悔 棋 的 操作 ， 将 多 个 试验 性 的 提交 合并 为 一 个 完整 的 提交 。 











以 DEMO 版 本 库 为 例 ， 看 看 版 本 库 最 近 的 三 次 提交 。 





$ git log --stat --pretty=oneline -3 
2b452066ef6e92bceb999cf94fcce24afb652259 commit with --amend test. 

README | 1+ 

1 files changed, 1 insertions(+), 0 deletions(-) 
613486c17842d139871egf1boge9191d2b6177c9f 偷懒 了 ， 直 接 用 -a 参数 直接 提交 。 

src/hello.h | 1 + 

1 files changed, 1 insertions(+), 0 deletions(-) 
48456abfaeab706a44880eabcd63ea14317cgbe9 add hello.h 

src/hello.h | 1 + 

1 files changed, 1 insertions(+), 0 deletions(-) 


















































想 要 将 最 近 的 两 个 提交 压缩 为 一 个 ， 并 把 提交 六 明 改 为 “modify 
hello.h”， 可 以 使 用 如 下 方法 进行 操作 。 


(1) 使 用 --soft 参 数 调用 重 置 命令 ， 回 到 最 近 两 次 提交 之 前 。 





$ git reset --soft HEADAA 








(2) 俘 看 版 本 状态 和 最 新 日 志 。 





$ git status 
# On branch master 
# Changes to be committed: 


# (use "git reset HEAD <file>..." to unstage) 
## 

# modified: README 

# modified: src/hello.h 

# 

$ git log -1 


commit 48456abfaeab706a44880eabcd63ea14317c0be9 
Author: Jiang Xin <jiangxin@ossxp.com> 
Date: Tue Dec 7 19:39:10 2010 +0800 

add hello.h 





(3) 执行 提交 操作 ， 即 完成 最 新 两 个 提交 压缩 为 一 个 提交 的 操 
作 。 





$ git commit -m "modify hello.h" 
[master b6foboa] modify hello.h 
2 files changed, 2 insertions(+), 0 deletions(-) 





(4) 看 看 提交 日 志 ,“ 多 步 悔 棋 ” 操 作成 功 。 





$ git log --stat --pretty=oneline -2 
b6foboa5237bc85de1863dbd1c05820f8736c76f modify hello.h 
README | 1+ 


src/hello.h | 1 + 

2 files changed, 2 insertions(+), 0 deletions(-) 
48456abfaeab706a44880eabcd63eal14317cgbe9 add hello.h 
src/hello.h | 1 + 

1 files changed, 1 insertions(+), 0 deletions(-) 


二 一 


电影 《 回 到 未 来 》 (Back to Future) 第 二 集 ， 老 毕 福 偷 走时 光 车 ， 
到 过 去 〈1955 年 ) 给 了 小 毕 福 一 本 书 ， 导 致 未 来 大 变 。 





也 就 是 过 去 的 杀 个 时 间 
时 间 线 被 扭曲 


图 12-1 布朗 博士 正在 解释 为 何 产 生 两 个 平行 的 未 来 





Git 这 一 台 “ 时 光 机 ”也 有 这 样 的 能 力 ， 或 者 说 也 具有 这 样 的 行为 。 更 
改 历 史 提 交 ‘SHA1 哈 希 值 变 更 ) 后 ， 即 使 后 续 提 交 的 内 容 和 属性 都 一 
致 ， 但 是 因为 后 续 提 交 中 有 一 个 属性 是 父 提交 的 SHA1 哈 希 值 ， 所 以 一 
个 历史 提交 的 改变 会 引起 连锁 变化 ， 导 致 所 有 的 后 续 提 交 都 发 生变 化 ， 








形成 两 条 平行 的 时 间 线 : 一 个 是 变更 前 的 提交 时 间 线 ， 男 外 一 条 是 更 改 
历史 后 新 的 提交 时 间 线 。 


把 此 次 实践 比喻 成 一 次 电影 “《 回 到 未 来 》) 担 摄 的 话 ， 舞 台 依 然 
是 之 前 的 DEMO 版 本 库 ， 而 剧本 是 这 样 的 。 





角色 : 最 近 的 六 次 提交 。 分 别 依据 提交 顺序 ， 编 号 为 A、B、C、 


D、 E F。 





$ git 1og --oneline -6 

b6foboa modify hello.h 

48456ab add hello.h 

3488f2c move .gitignore outside also works. 
b3af728 ignore object files. 

d71ce92 Hello world initialized. 

cO24f34 README is from welcome.txt. 


亲 半 和 半 亲 和 亲 宁 
PmHOOMT 





坏蛋 : 提交 DD。 


即 不 再 需要 对 .gitignore 文 件 进行 移动 的 提交 ， 或 者 这 个 提交 将 和 前 
一 次 提交 《〈C) 压缩 为 一 个 。 


. 前 奏 : 故事 人 物 依次 出 场 ， 坏 蛋 D 在 图 中 被 特殊 标记 ， 如 图 12-2 
所 示 。 


图 12-2 ”提交 示意 图 


第 一 幕 : 抛弃 提交 DD， 将 正确 的 提交 已 和 F 重 新 “嫁接 ”到 提交 C 


上 ， 最 终 坏蛋 被 消灭 ， 如 图 12-3 所 示 。 





图 12-3 ”抛弃 DD 提交 示意 图 


-第 二 幕 : 坏蛋 D 被 C 感 化 ， 融 合 为 “CD ”复合 体 ， 忆 和 F 重 新 “ 嫁 


接 到 CD 复合 体 上 ， 最 终 大 团圆 结局 ， 如 图 12-4 所 示 。 





图 12-4 C、D 提 交合 并 示意 图 


. 道具 : 分 别 使 用 三 辆 不 同 的 时 光 车 来 完成 “ 回 到 未 来 ”。 


它们 分 别 是 :“ 核 能 跑车 ” 


操作 、“ 蒸 汽 为 动力 的 飞行 火车 ”一 一 交互 式 变 基 操 作 。 





12.3.1 时 间 旅 行 一 


拣选 操作 、“ 清 涪 能 源 飞 车 ”一 一 变 基 


《 回 到 未 来 》 第 一 集 ， 布 明博 士 设 计 的 第 一 亚 时 间 旅 行车 是 一 辆 跑 
车 ， 使 用 核燃料 : 钙 。 与 之 对 应 ， 此 次 实践 使 用 的 工具 也 没有 太 出 乎 想 
象 之 外 ， 用 一 条 新 的 指令 一 一 拣选 指令 (git cherry-pick) 实现 提交 在 新 
的 分 文 上 “ 重 放 ”。 





撕 选 指令 一 一 git cherry-pick， 其 含义 是 从 众多 的 提交 中 挑选 出 一 个 
提交 应 用 在 当前 的 工作 分 文中 。 该 命令 需要 提供 一 个 提交 ID 作 为 参数 ， 
操作 过 程 相当 于 将 该 提交 导出 为 补丁 文件 ， 然 后 在 当前 HEAD 上 重 放 ， 
形成 无 论 内 容 还 是 提交 说 明 都 一 致 的 提交 。 











首先 对 版 本 库 要 “ 参 演 ” 的 角色 进行 标记 ， 使 用 尚未 正式 介绍 的 命令 
git tag 无 非 束 是 在 特定 命名 空间 建 了 “固定 ”的 引用 ， 用 于 对 提交 进行 


标识 ) 。 





$ git tag F 

$ git tag E HEADA^ 
$ git tag D HEADAA 
$ git tag C HEADAAA 
$ git tag B HEAD~4 
$ git tag A HEAD~5 





通过 日 志 ， 可 以 看 到 被 标记 的 6 个 提交 。 





$ git log --oneline --decorate -6 

b6foboa (HEAD, tag: F, master) modify hello.h 

48456ab (tag: E) add hello.h 

3488f2c (tag: D) move .gitignore outside also works. 
b3af728 (tag: C) ignore object files. 

d71ce92 (tag: hello 1.0, tag: B) Hello world initialized. 
co024f34 (tag: A) README is from welcome.txt. 


1. 现 在 演出 第 一 幕 : 干掉 坏 香 D 
(1) 执行 git checkout 命 令 ， 暂 时 将 HEAD 头 指针 切换 到 C。 


切换 过 程 显 示 处 于 非 跟踪 状态 的 警告 ,没有 关系 ， 因 为 剧情 需要 。 





$ git checkout C 

Note: checking out 'C'. 

You are in 'detached HEAD' state. You can look around, make experimental 

changes and commit them, and you can discard any commits you make in this 

state without impacting any branches by performing another checkout. 

If you want to create a new branch to retain commits you create, you may 

do so (now or later) by using -b with the checkout command again. Example: 
git checkout -b new_branch_name 

HEAD is now at b3af728... ignore object files. 





(2) 执行 拣选 操作 将 E 提 交 在 当前 HEAD 上 重 放 。 


因为 E 和 master^ 显 然 指向 同一 角色 ， 因 此 可 以 用 下 面 的 语法 。 





$ git cherry-pick masterA^ 

[detached HEAD fagob076] add hello.h 

1 files changed， 1 insertions(+), 0 deletions(-) 
create mode 100644 src/hello.h 





(3) 执行 拣选 操作 将 F 提 交 在 当前 HEAD 上 重 放 。 


F 和 和 master 也 具有 相同 指 问 。 





$ git cherry-pick master 
[detached HEAD f677821] modify hello.h 
2 files changed, 2 insertions(+), 0 deletions(-) 








(4) 通过 日 志 可 以 看 到 坏 重 D 已 经 不 在 了 。 





$ git log --oneline --decorate -6 

f677821 (HEAD) modify hello.h 

fa0b076 add hello.h 

b3af728 (tag: C) ignore object files. 

d71ce92 (tag: hello 1.0, tag: B) Hello world initialized. 
co024f34 (tag: A) README is from welcome.txt. 

63992f0 restore file: welcome.txt 








(5) 通过 日 志 还 可 以 看 出 来 ， 最 新 两 次 提交 的 原始 创作 日 期 
(CAuthorDate) 和 提交 日 期 (CommitDate) 不 同 。AuthorDate 是 拣选 提 
交 的 原始 更 改 时 间 ， 而 CommitDate 是 拣选 操作 时 的 时 间 ， 因 此 拣选 后 的 
新 提交 的 SHA1 哈 希 值 也 不 同 于 所 拣选 的 原 提 交 的 SHA1 哈 希 值 。 





$ git log --pretty=fuller --decorate -2 
commit f677821dfc15acc22ca41b48b8ebaab5ac2d2fea (HEAD) 


Author: Jiang Xin <jiangxin@ossxp.com> 
AuthorDate: Sun Dec 12 12:11:00 2010 +0800 
Commit: Jiang Xin <jiangxin@ossxp.com> 


CommitDate: Sun Dec 12 16:20:14 2010 +0800 
modify hello.h 
commit faob076de600a53e8703545c299090153c6328a8 
Author: Jiang Xin <jiangxin@ossxp.com> 
AuthorDate: Tue Dec 7 19:39:10 2010 +0800 
Commit: Jiang Xin <jiangxin@ossxp.com> 
CommitDate: Sun Dec 12 16:18:34 2010 +0800 
add hello.h 





(6) 最 重要 的 一 步 操作 ， 就 是 要 将 master 分 文章 置 到 新 的 提交 


ID (〈f677821) 上 。 


下 面 的 切换 操作 使 用 了 reflog 的 语法 ， 即 HEADQ@{1} 相 当 于 切换 回 
master 分 支 前 的 HEAD 指 向 ， 即 f677821。 





$ git checkout master 

Previous HEAD position was f677821... modify hello.h 
Switched to branch 'master' 

$ git reset --hard HEAD@{1} 

HEAD is now at f677821 modify hello.h 





(7) 使 用 qgit 得 看 版 本 库 提 交 历 史 ， 如 图 12-5 所 示 。 


Rev list 


Short Log 


add hello.h 
modify hello.h 
[Ej]add hello.h 


hello.h 


move .gitignore outside also works. 


files. 


[DJ] 

[Cjignore object 

Hello world initialized. 
四 README is from welcome .txt. 
restore file: welcome .txt 


图 12-5 dsit 显 示 的 提交 分 支 图 


2. 幕 布 拉 上 ， 后 台 重 新 布景 


为 了 第 二 幕 能 够 顺利 演出 ， 需 要 将 master 分 文 重 新 置 回 到 提交 下 








上 上 上。 执行 下 面 的 操作 完成 “重新 布景 ” 





$ git checkout master 


Already 


on 'master' 


$ git reset --hard F 
HEAD is now at b6foboa modify hello.h 
$ git 1og --oneline --decorate -6 





b6foboa (HEAD, tag: F, master) modify hello.h 
48456ab (tag: E) add hello.h 
3488f2c (tag: D) move .gitignore outside also works. 
b3af728 (tag: C) ignore object files. 
d71ce92 (tag: hello 1.0, tag: B) Hello world initialized. 
co024f34 (tag: A) README is from welcome.txt. 
慎 . 己 "FE 昔日 中 ys 
布景 完毕 ， 大 幕 即将 再 次 拉 开 。 
Ny A -一 LE XE >» 一 昌 
3. 现 在 演出 第 二 幕 : 坏 重 D 被 感化 ， 融 入 社会 


(1) 执行 git checkout 命 令 ， 和 暂时 将 HEAD 头 指针 切换 到 坏 香 D。 


O 


Author 


jang Xin<jiangxin... 
jang Xin<jiangxin... 
Jiang Xin<jiangxin... 
Jiang Xin<jiangxin... 
Jiang Xin<jiangxin... 
Jiang Xin<jiangxin... 
Jiang Xin<jiangxin... 
Jiang Xin<jiangxin... 


Author Date 


10-12-12 PM12:11 
10-12-7 PM7:39 
10-12-12 PM12:11 
10-12-7 PM7:39 
10-12-7 PM7:34 
10-12-7 PM7:21 
10-12-7 PM6:33 
10-12-7 PM2:50 
10-12-7 PM2:32 








切换 过 程 显 示 处 于 非 跟踪 状态 的 警告 ,没有 关系 ， 因 为 剧情 需要 。 





$ git checkout D 

Note: checking out 'D'. 

You are in 'detached HEAD' state. You can look around, make experimental 

changes and commit them, and you can discard any commits you make in this 

state without impacting any branches by performing another checkout. 

If you want to create a new branch to retain commits you create, you may 

do so (now or later) by using -b with the checkout command again. Example: 
git checkout -b new_branch_name 

HEAD is now at 3488f2c... move .gitignore outside also works. 





(2) 悔 棋 两 次 ， 以 便 将 C 和 DD 融合 。 





$ git reset --soft HEADAA 





(3) 执行 提交 ， 提 有 交 说 明 重 用 C 提 交 的 提交 说 明 。 





$ git commit -C C 

[detached HEAD 53e621c] ignore object files. 

1 files changed, 3 insertions(+), 0 deletions(-) 
create mode 100644 .gitignore 





(4) 执行 拣选 操作 将 提交 在 当前 HEAD 上 重 放 。 





$ git cherry-pick E 

[detached HEAD 1f99f82] add hello.h 

1 files changed, 1 insertions(+), 0 deletions(-) 
create mode 100644 src/hello.h 





(5) 执行 拣选 操作 将 F 提 交 在 当前 HEAD 上 重 放 。 





$ git cherry-pick F 
[detached HEAD 2f13d3a] modify hello.h 
2 files changed, 2 insertions(+), 0 deletions(-) 





(6) 通过 


的 标签 。 


日 志 可 以 看 到 提交 C 和 D 被 融合 ， 所 以 在 日 志 中 看 不 到 C 





$ git log --oneline --decorate -6 

2f13d3a (HEAD) modify hello.h 

1f99f82 add hello.h 

53e621c ignore object files. 

d71ce92 (tag: hello 1.0, tag: B) Hello world initialized. 
cO24f34 (tag: A) README is from welcome.txt. 

63992f0 restore file: welcome.txt 





(7) 最 重要 的 一 步 操作 ， 束 是 要 将 master 分 文 指 癌 新 的 提交 
ID (2f13d3a) 上 。 


下 面 的 切换 操作 使 用 了 reflog 的 语法 ， 即 HEAD@{1} 相 当 于 切换 回 
master 分 支 前 的 HEAD 指 向 ， 即 2f13d3a。 





$ git checkout master 

Previous HEAD position was 2f13d3a... 
Switched to branch 'master' 

$ git reset --hard HEAD@{1} 

HEAD is now at 2f13d3a modify hello.h 


modify hello.h 





(8) 使 用 gitk 查 看 版 本 库 的 提交 历史 ， 如 图 12-6 所 示 。 

























图 12-6 ”gi 人 k 显 示 的 提交 分 支 图 





modify hello.h Jiang Xin <jiangxin@ossxp.com> | 2010-12-12 12:11:00 
和 外 add helloh Jiang Xin <jiangxin@ossxp.com> 2010-12-07 19:39:10 
ignore object files. Jiang Xin <jiangxin@ossxp.corn> 2010-12-07 19:21:39 
PS modify hello.h Jiang Xin <jiangxin@ossxp.com> 2010-12-12 12:11:00 
<E add hello.h Jiang Xin <jiangxin@ossxp.corm> 2010-12-07 19:39:10 
<D move .gitignore outside also works. Jiang Xin <jiangxin@@ossxp.com> 2010-12-07 19.34:37 

C| ignore object files Jiang Xin <jiangxin@ossxp.com> 2010-12-07 19:21:39 

一 Hello world initialized. | Jiang Xin <jiangxin@ossxp.com> 2010-12-07 18:33:45 
<A| README is from welcome txt. Jiang Xin <jiangxin@ossxp.com> 2010-12-07 14:50:02 
restore file: welcome.txt Jiang Xin <jiangxin@ossxp.com> 2010-12-07 14:32:57 


4. 别 忘 了 后 台 的 重新 布景 





为 了 接 下 来 的 时 间 旅 行 二 能 够 顺利 开始 ， 需 要 重新 布景 ， 将 master 
分 文 重 新 置 回 到 提交 F 





$ git checkout master 

Already on 'master 

$ git reset --hard F 

HEAD is now at b6foboa modify hello.h 

用 法 1: git rebase --onto <newbase> <since> <till> 
法 2: git rebase --onto <newbase> <since> [HEAD] 
法 3: git rebase [--onto <since>] <since> <till> 
法 4: git rebase [--onto <since>] <since> [HEAD] 















































Se ie i 








12.3.2 ”时间 旅行 二 


《 回 到 未 来 》 第 二 集 ， 布 明博 士 改进 的 时 间 旅 行车 使 用 了 未 来 科 
技 ， 是 陆 天 两 用 的 飞车 ， 而 且 燃 料 不 再 依赖 核 物质 ， 而 是 使 用 无 处 不 在 
的 生活 垃圾 。 而 此 次 实践 使 用 的 工具 也 进行 了 升级 ， 采 用 强大 的 中 it 


rebase 命 令 。 


命令 git rebase 是 对 提交 执行 变 基 操作 ， 即 可 以 实现 将 指定 范围 的 提 
区 “嫁接 ”到 男 外 一 个 提交 之 上 。 其 常用 的 命令 行 格 式 有 : 






































用 法 1: git rebase --onto <newbase> <since> <till> 
用 法 2: git rebase --onto <newbase> <since> 

用 法 3: git rebase <since> <till> 

用 法 4: git rebase <since> 























用 法 6: git rebase --continue 
用 法 7: git rebase --skip 
用 法 8: git rebase --abort 





























/ 
/ 
| 
用 法 5: git rebase -i ... 
| 
| 
上 


不 要 被 上 面 的 语法 吓 到 ， 用 法 5 会 在 下 节 《〈 时 间 旅 行 三 ) 中 予以 介 
绍 ， 后 三 种 用 法 则 是 变 基 运行 过 程 被 中 断 时 可 采用 的 命令 一 一 继续 变 基 
或 终止 等 。 





用 法 6 是 在 变 基 这 到 冲突 而 暂停 的 情况 下 ， 先 完成 冲突 解决 ( 添 
加 到 暂 存 区 ， 不 提交 ) ， 然 后 在 恢复 变 基 操作 的 时 候 使 用 该 命 


. 用 法 7 是 在 变 基 遇 到 冲突 而 暂停 的 情况 下 ， 跳 过 当前 提交 的 时 候 
使 用 。 


用 法 8 是 在 变 基 遇 到 冲突 而 暂停 的 情况 下 ， 终 止 变 基 操作 ， 回 到 
之 前 的 分 支 时 候 使 用 。 


而 前 四 个 用 法 如 果 把 省 略 的 参数 补 上 “《 方 括号 内 是 省 略 把 的 参 
数 ) ， 看 起 来 和 用 法 1 就 都 一 致 了 。 


下 面 就 以 归 一 化 的 git rebase 命 令 格 式 来 介绍 其 用 法 。 





命令 格式 : git rebase --onto <newbase> <since> <till> 





变 基 操作 的 过 程 : 
(1) 首先 会 执行 git checkout 切 换 到 <till>。 


因为 会 切换 到 <tillj>， 因 此 如 果 <till> 指 向 的 不 是 一 个 分 支 《 如 


master) ， 则 变 基 操作 是 在 detached HEAD (分 离 头 指针 ) 状态 进行 
的 ， 当 变 基 结 束 后 ， 还 要 像 在 “时 间 旅 行 一 ”中 那样 ， 对 master 分 文 执行 
重 置 以 实现 变 基 结果 在 分 文中 生效 。 





(2) 将 <since>..<til> 所 标识 的 提交 范围 写 到 一 个 临时 文件 中 。 


还 记得 前 面 介绍 的 版 本 范围 语法 吗 ，<since>..<till> 是 指 包 括 <till> 的 
所 有 历史 提交 排除 <since> 及 <since> 的 历史 提交 后 形成 的 版 本 范围 。 


(3) 将 当前 分 文 强制 重 置 (git reset--hard) 到 <newbase>。 


相当 于 执行 : git reset--hard<newbase>。 





(4) 从 保存 在 临时 文件 中 的 提交 列表 中 ， 将 提交 逐一 按 顺 序 重 新 
提交 到 重 置 之 后 的 分 文 上 。 





(5) 如 果 遇 到 提交 已 经 在 分 文中 包含 ， 则 跳 过 该 提交 。 


(6) 如 果 在 提交 过 程 遇 到 冲突 ， 则 变 基 过 程 暂 集 。 用 户 解 决 冲突 
后 ， 执 行 git rebase--continue 继 续 变 基 操 作 。 或 者 执行 git rebase--skip 跳 过 
此 提交 。 或 者 执行 git rebase--abort 束 此 终止 变 基 操 作 切 换 到 变 基 前 的 分 
Ss 


很 显然 为 了 执行 将 E 和 F 提 交 路 过 提交 D, “ 嫌 ?到 提交 C 上 。 可 以 
如 此 执行 变 基 命令 : 


$ git rebase --onto C EA F 








因为 E^ 等 价 于 D， 并 且 F 和 当前 HEAD 的 指向 相同 ， 因 此 可 以 这 样 操 
作 : 





$ git rebase --onto CD 





有 了 对 变 基 命令 的 理解 ， 残 可 以 开始 新 的 “ 回 到 未 来 ”之 旅 了 。 


确认 舞台 已 经 布置 完毕 





$ git status -s -b 

## master 

$ git log --oneline --decorate -6 

b6foboa (HEAD, tag: F, master) modify hello.h 

48456ab (tag: E) add hello.h 

3488f2c (tag: D) move .gitignore outside also works. 
b3af728 (tag: C) ignore object files. 

d71ce92 (tag: hello 1.0, tag: B) Hello world initialized. 
co024f34 (tag: A) README is from welcome.txt. 





1. 现 在 演出 第 一 右 : 干掉 坏 重 D 


(1) 执行 变 基 操作 。 








因为 下 面 的 变 基 操 命令 行使 用 了 参数 F。F 是 一 个 里 程 碑 指 疝 一 个 所 
交 ， 而 非 master， 会 导致 后 面 变 基 完 成 后 还 需要 对 master 分 文 执行 重 
置 。 在 第 二 幕 中 使 用 分 文 master 作 为 参数 ， 会 及 现 省 事 不 少 。 





$ git rebase --onto C EA F 

First, rewinding head to replay your work on top of it... 
Applying: add hello.h 

Applying: modify hello.h 





(2) 最 后 一 步 必 需 的 操作 ， 就 是 要 将 master 分 文 指 癌变 基 后 的 提交 


下 面 的 切换 操作 使 用 了 reflog 的 语法 ， 即 HEAD@{1} 相 当 于 切换 回 
master 分 支 前 的 HEAD 指 向 ， 即 3360440。 





$ git checkout master 

Previous HEAD position was 3360440... modify hello.h 
Switched to branch 'master' 

$ git reset --hard HEAD@{1} 

HEAD is now at 3360440 modify hello.h 





(3) 经 过 检查 ， 操 作 完 毕 ， 收 工 。 





$ git log --oneline --decorate -6 

3360440 (HEAD, master) modify hello.h 

1ef3803 add hello.h 

b3af728 (tag: C) ignore object files. 

d71ce92 (tag: hello 1.0, tag: B) Hello world initialized. 
co024f34 (tag: A) README is from welcome.txt. 

63992f0 restore file: welcome.txt 





2. 幕 布 拉 上 ， 后 台 重 新 布景 





为 了 第 二 幕 能 够 顺利 演出 ， 需 要 将 master 分 文 重 新 置 回 到 提交 F 
上 上 上。 执行 下 面 的 操作 完成 “重新 布景 ”。 








$ git checkout master 

Already on 'master' 

$ git reset --hard F 

HEAD is now at b6foboa modify hello.h 





布景 完毕 ， 大 幕 即将 再 次 拉 开 。 


3. 现 在 演出 第 二 幕 : 坏 重 D 被 感化 ， 融 入 社会 


(1) 执行 git checkout 命 令 ， 和 暂时 将 HEAD 头 指针 切换 到 坏蛋 D。 





切换 过 程 显 示 处 于 非 跟踪 状态 的 警告 ,没有 关系 ， 因 为 剧情 需要 。 





$ git checkout D 

Note: checking out 'D'. 

You are in 'detached HEAD' state. You can look around, make experimental 

changes and commit them, and you can discard any commits you make in this 

state without impacting any branches by performing another checkout. 

If you want to create a new branch to retain commits you create, you may 

do so (now or later) by using -b with the checkout command again. Example: 
git checkout -b new_branch_name 

HEAD is now at 3488f2c... move .gitignore outside also works. 





(2) 悔 棋 两 次 ， 以 便 将 C 和 DD 融合 。 





$ git reset --Soft HEADAA 





(3) 执行 提交 ， 提 交 说 明 重 用 C 提 交 的 提交 说 明 。 





$ git commit -C C 

[detached HEAD 2d020b6] ignore object files. 

1 files changed, 3 insertions(+), 0 deletions(-) 
create mode 100644 .gitignore 





(4) 记 住 这 个 提交 ID: 2d020b6。 





用 里 程 碑 是 记忆 提交 ID 的 最 好 方法 : 





$ git tag newbase 
$ git rev-parse newbase 
2d020b62034b7a433f80396118bc3f66a60f296f 


(5) 执行 变 基 操作 ， 将 E 和 F 提 交 “ 炮 接 ” 人 Bnewbase 上 。 


下 面 的 变 基 操 命令 行 没 有 像 之 前 的 操作 那样 使 用 参数 F， 而 是 使 用 
分 文 master。 所 以 接 下 来 的 变 基 操作 会 直接 修改 master 分 支 ， 而 无 须 再 
对 master 进 行 重 置 操 作 。 








$ git rebase --onto newbase E^ master 

First, rewinding head to replay your work on top of it... 
Applying: add hello.h 

Applying: modify hello.h 





(6) 看 看 提交 日 志 ， 看 到 提交 C 和 提交 DD 都 不 见 了 ， 代 之 以 融合 后 


的 提交 newbase。 





还 可 以 看 到 最 新 的 提交 除了 和 HEAD 的 指向 一 致 ， 也 和 master 分 支 
的 指 癌 一 致 。 





$ git log --oneline --decorate -6 

2495dc1 (HEAD, master) modify hello.h 

6349328 add hello.h 

2d020b6 (tag: newbase) ignore object files. 

d71ce92 (tag: hello 1.0, tag: B) Hello world initialized. 
co024f34 (tag: A) README is from welcome.txt. 

63992f0 restore file: welcome.txt 





(7) 当前 的 确 已 经 在 master 分 支 上 了 ， 操 作 全 部 完成 。 





$ git branch 
* master 





(8) 清理 一 下 ， 然 后 收工 。 


前 面 的 操作 中 为 了 方便 创建 了 标识 提交 的 新 里 程 碑 newbase， 这 个 
里 程 碑 现在 没有 什么 用 处 了 ， 删 除 吧 。 


$ git tag -d newbase 
Deleted tag 'newbase' (was 2d020b6) 


4. 别 忘 了 后 人 台 的 重新 布景 


为 了 接 下 来 的 时 间 旅 行 三 能 够 顺利 开始 ， 需 要 重新 布景 ， 将 master 
分 文 重 新 置 回 到 提交 F 上 。 


$ git checkout master 

Already on "master 

$ git reset --hard F 

HEAD is now at b6foboa modify hello.h 


12.3.3 时间 旅 行 三 


《 回 到 未 来 》 第 三 集 ， 成 了 铁匠 的 布朗 博士 手工 打造 了 可 以 时 光 旅 
行 的 飞行 火车 ， 使 用 蒸汽 作为 动力 。 这 款 时 间 旅 行 火 车 更 大 、 更 安全 、 
更 舒适 ， 适 合 一 家 四 口外 加 宠物 的 时 空 旅行 。 与 之 对 应 本 次 实践 也 将 采 
用 “手工 打造 ” 交互 式 变 基 。 

















交互 式 变 基 就 是 在 上 一 市 介绍 的 变 基 命 令 的 基础 上 ， 添 加 了 -i 参 
数 ， 在 变 基 的 时 候 进 入 一 个 交互 界面 。 使 用 了 交互 界面 的 变 基 操 作 ， 不 
是 自动 化 变 基 转换 为 手动 确认 那么 没有 技术 含量 ， 而 是 充满 了 魔法 。 








执行 交互 式 变 基 操 作 ， 会 将 <since>..<till> 的 提交 悉数 罗列 在 一 个 文 
件 中 ， 然 后 日 动 打开 一 个 编辑 器 来 编辑 这 个 文件 。 可 以 通过 修改 文件 的 
内 容 设 定 变 基 操作 ， 实 现 删 除 提 交 、 将 多 个 提交 压缩 为 一 个 提交 、 更 改 
提交 的 顺序 ， 以 及 更 改 历 史 提 交 的 提交 说 明 等 。 








例如 ， 下 面 的 界面 就 是 针对 当前 DEMO 版 本 库 执行 的 交互 式 变 基 时 
编辑 器 打开 的 文件 : 





pick b3af728 ignore object files. 

pick 3488f2c move .gitignore outside also works. 
pick 48456ab add hello.h 

pick b6foboa modify hello.h 

# Rebase d71ce92.,b6foboa onto d71ce92 


# Commands: 

# p, pick = use commit 

# Tr, reword = use commit, but edit the commit message 

# ee, edit = use commit, but stop for amending 

# ss, Squash = use commit, but meld into previous commit 

# f, fixup = like "squash", but discard this commit's log message 

# x <cmd>, exec <cmd> = Run a shell command <cmd>, and stop if it fails 
# 

# If you remove a line here THAT COMMIT WILL BE LOST. 

# However, if you remove everything, the rebase will be aborted. 





从 该 文件 中 可 以 看 出 : 
: 开头 的 四 行 由 上 到 下 依次 对 应 于 提交 C、D、E、F。 
` 前 四 行 默 认 的 动作 都 是 pick， 即 应 用 此 提交 。 


` 参考 文件 中 的 注释 ， 可 以 通过 修改 动作 名 称 ， 在 变 基 的 时 候 执行 
特定 操作 。 


` 动作 tewotd， 或 者 简写 为 f。 在 变 基 时 会 应 用 此 提交 ， 但 是 在 提交 
的 时 候 允 许 用 户 修改 提交 说 明 。 这 个 功能 在 Git 1.6.6 之 后 开始 提供 ， 对 
于 修改 历史 提交 的 提交 说 明 非 常 方便 。 对 于 老 版 本 的 Git 没 有 tewotd 动 
作 ， 可 以 使 用 edit 动 作 。 


- 动作 edit， 或 者 简写 为 e。 也 会 在 变 基 时 应 用 此 提交 ， 但 是 会 在 应 
用 后 暂停 变 基 ， 提 示 用 户 使 用 git commit--amend 执 行 提 交 ， 以 便 对 提交 
进行 修补 。 当 用 户 执行 git commit--amend 完 成 提交 后 ， 还 需要 执行 git 
rebase--continue 继 续 变 基 操 作 。 用 户 在 变 基 暂停 状态 下 可 以 执行 多 次 提 
交 ， 从 而 实现 把 一 个 提交 分 解 为 多 个 提交 。edit 动 作 非 常 强大 ， 对 于 老 
版 本 的 Git 没 有 reword 动 作 ， 可 以 使 用 edit 动 作 实 现 相同 的 效果 。 


-动作 squash， 或 者 简写 为 s。 该 提交 会 与 前 面 的 提交 压缩 为 一 个 。 


-动作 fixup， 或 者 简写 为 f。 类 似 动作 squash， 但 是 此 提交 的 提交 说 
明 被 丢弃 。 这 个 功能 在 Git1.7.0 之 后 开始 提供 ， 老 版 本 的 Git 还 是 使 用 
squash 动 作 吧 。 


以 通过 修改 变 基 任 务 文件 中 各 个 提交 的 先后 顺序 ， 进 而 改变 最 


终 变 基 后 提交 的 先后 顺序 。 


过 


“ 可 以 修改 变 基 任务 文件 ， 删 除 包 含 相 应 提交 的 行 ， 这 样 该 提交 就 


不 会 被 应 用 ， 进 而 在 变 基 后 的 提交 中 被 删除 。 





有 了 对 交互 式 变 基 命令 的 理解 ， 束 可 以 开始 新 的 “ 回 到 未 来 ”之 旅 
站 


确认 舞台 已 经 布置 完毕 。 





$ git status -s -b 

## master 

$ git log --oneline --decorate -6 

b6foboa (HEAD, tag: F, master) modify hello.h 

48456ab (tag: E) add hello.h 

3488f2c (tag: D) move .gitignore outside also works. 
b3af728 (tag: C) ignore object files. 

d71ce92 (tag: hello 1.0, tag: B) Hello world initialized. 
co024f34 (tag: A) README is from welcome.txt. 





过 


1. 现 在 演出 第 一 右 : 干掉 坏 重 D 





(1) 执行 交互 式 变 基 操作 。 





$ git rebase -i D^ 





(2) 目 动 用 编辑 器 修改 文件 。 文 件 内 容 如 下 : 





pick 3488f2c move .gitignore outside also works. 
pick 48456ab add hello.h 

pick b6foboa modify hello.h 

Rebase b3af728.,b6foboa onto b3af728 


Commands: 

p， pick = use commit 

r， reword = use commit, but edit the commit message 

e, edit = use commit, but stop for amending 

s, Squash = use commit, but meld into previous commit 

f, fixup = like "squash", but discard this commit's log message 

x <cmd>, exec <cmd> = Run a shell command <cmd>, and stop if it fails 


If you remove a line here THAT COMMIT WILL BE LOST. 
However, if you remove everything, the rebase will be aborted. 


亲 亲 亲 亲 亲 半 亲 亲 亲 半 亲 亲 六 


(3) 将 第 一 行 删 除 ， 使 得 上 面 的 文件 看 起 来 像 是 这 样 〈 省 略 井 号 
开始 的 注释 ) : 








pick 48456ab add hello.h 
pick b6foboa modify hello.h 





(4) 保存 退出 。 


变 基 上 自动 开始 ， 即 刻 完 成 。 


显示 下 面 的 内 容 : 





Successfully rebased and Updated refs/heads/master. 





(5) 看 看 日 志 。 当 前 分 支 master 已 经 完成 变 基 ， 消 灭 了 “坏蛋 D?”。 





$ git log --oneline --decorate -6 

78e5133 (HEAD, master) modify hello.h 

11eea7e add hello.h 

b3af728 (tag: C) ignore object files. 

d71ce92 (tag: hello 1.0, tag: B) Hello world initialized. 
co024f34 (tag: A) README is from welcome.txt. 

63992f0 restore file: welcome.txt 





2. 幕 布 拉 上 ， 后 台 重 新 布景 





为 了 第 二 和 幕 能 够 顺利 演出 ， 需 要 将 master 分 文 重 新 置 回 到 提交 F 
上 上。 执行 下 面 的 操作 完成 < 重新 布景 ”。 








$ git checkout master 
Already on "master 
$ git reset --hard F 


HEAD is now at b6foboa modify hello.h 





布景 完毕 ， 大 幕 即将 再 次 拉 开 。 


3. 现 在 演出 第 二 幕 : 坏 重 D 被 感化 ， 融 入 社会 





(1) 同样 执行 交互 式 变 基 操 作 ， 不 过 因为 要 将 C 和 D 压 缩 为 一 个 ， 
因此 变 基 从 C 的 父 提 交 开 始 。 





$ git rebase -i CA 





(2) 目 动用 编辑 器 修改 文件 。 文 件 内 容 如 下 《忽略 井 号 开始 的 注 
释 ) : 





pick b3af728 ignore object files. 

pick 3488f2c move .gitignore outside also works. 
pick 48456ab add hello.h 

pick b6foboa modify hello.h 





(3) 修改 第 二 行 〈《 提 交 D) ， 将 动作 由 pick 修 改 为 squash。 


修改 后 的 内 容 如 下 : 





pick b3af728 ignore object files. 

squash 3488f2c move .gitignore outside also works. 
pick 48456ab add hello.h 

pick b6foboa modify hello.h 





(4) 保存 退出 。 目 动 开 始 变 基 操作 ， 在 执行 到 squash 命 令 设 定 的 
提交 时 ， 进 入 提交 前 的 日 志 编 辑 状态 。 





显示 的 待 编辑 日 志 如 下 。 很 明显 C 和 D 的 提交 说 明显 示 在 了 一 起 。 





# This is a _ combination of 2 commits. 
# The first commit's message is: 
ignore object files. 

# This is the 2nd commit message: 
move .gitignore outside also works. 





(5) 保存 退出 ， 即 完成 squash 动 作 标 识 的 提交 合并 及 后 续 变 基 操 
作 。 





看 看 提 萄 日志， 看 到 提交 C 和 提交 D 都 不 见 了 ， 代 之 以 一 个 融合 后 
的 提交 出 现 。 





$ git log --oneline --decorate -6 

coc2a1a (HEAD, master) modify hello.h 

cle8b66 add hello.h 

db512c0 ignore object files. 

d71ice92 (tag: hello 1.0, tag: B) Hello world initialized. 
co024f34 (tag: A) README is from welcome.txt. 

63992f0 restore file: welcome.txt 








(6) 可 以 看 到 融合 C 和 D 的 提交 日 志 实 际 上 有 是 两 者 日 志 的 融合 。 在 
前 面 单行 显示 的 日 志 中 看 不 出 来 。 











$ git cat-file -p HEADAA 

tree 00239a5d0daf9824a23cbf104d30af66af984e27 

parent d71ce9255b3b08c718810e4e31760198dd6da243 

author Jiang Xin <jiangxin@ossxp.com> 1291720899 +0800 
committer Jiang Xin <jiangxin@ossxp.com> 1292153393 +0800 
ignore object files. 

move .gitignore outside also works. 





时 光 旅 行 结束 了 ， 多 么 神奇 的 Git 呵 。 


1]24 天 弃 历 中 





历史 有 的 时 候 会 成 为 负担 。 例 如 一 个 人 使 用 的 版 本 库 有 一 天 需要 作 
为 公共 版 本 库 多 人 共享 ， 最 早 的 历史 可 能 不 希望 或 者 没有 必要 继续 保持 
存在 ， 需 要 一 个 抛弃 部 分 早期 历史 提交 的 精简 的 版 本 库 以 用 于 和 他 人 共 
译 。 册 比如 用 Git 做 文件 备份 ， 不 希望 备份 的 版 本 过 多 而 导致 不 必要 的 
磁盘 空间 占用 ， 同 样 会 有 精简 版 本 的 需要 : 只 保留 最 近 的 100 次 提交 ， 
抛弃 之 前 的 历史 提交 。 那 么 应 该 如 何 操作 呢 ? 














使 用 交互 式 变 基 当然 可 以 完成 这 样 的 任务 ， 但 是 如 果 有 历史 版 本 库 有 
成 百 上 干 个 ， 把 成 百 上 干 个 版 本 的 变 基 动作 中 有 pick 的 修改 为 fixup 可 真 
的 很 费事 ， 实 际 上 Git 有 更 简便 的 方法 。 


现在 DEMO 版 本 库 有 如 下 的 提交 记录 : 





$ git log --oneline --decorate 

coc2a1a (HEAD, master) modify hello.h 

cle8b66 add hello.h 

db512c0 ignore object files. 

d71ce92 (tag: hello 1.0, tag: B) Hello world initialized. 
co024f34 (tag: A) README is from welcome.txt. 
63992f0 restore file: welcome.txt 

7161977 delete trash files. (using: git add -u) 
2b31c19 (tag: old practice) Merge commit 'acc2f69' 
acc2f69 commit in detached HEAD mode. 

4902dc3 does master follow this new commit? 
e695606 which version checked in? 

aoc641e who does commit? 

9e8a761 initialized. 





如 果 希 望 把 里 程 碑 A (c024f34) 之 前 的 历史 提交 全 部 清除 ， 可 以 这 


样 操作 : 基于 里 程 碑 A 对 应 的 提交 构造 一 个 根据 区 《〈 即 没有 父 提 区 的 提 
区 ) ， 然 后 再 将 master 分 文 在 里 程 碑 A 之 后 的 提交 变 基 到 新 的 根 提 区 
上 ， 实 现 对 历史 提交 的 清除 。 





由 里 程 碑 A 对 应 的 提交 构造 出 一 个 根 提交 至少 有 两 种 方法 。 第 一 种 
方法 是 使 用 git commit-tree 命 令 ， 可 以 进行 如 下 操作 。 


(1) 查看 里 程 碑 A 指向 的 目录 树 。 


用 AA{tree} 语 法 访问 里 程 碑 A 对 应 的 目录 树 。 





$ git cat-file -p A^{tree} 
100644 blob 51dbfd25a804c30e9d8dc441740452534de8264b README 








(2) 使 用 git commit-tree 命 令 直 接 从 该 目录 树 创 建 提交 。 





$ echo "Commit from tree of tag A." | git commit-tree A^{tree} 
8f7f94ba6a9d94ecc1c223aa4b311670599e1f86 





(3) 命令 git commit-tree 的 输出 是 一 个 提交 的 SHA1 哈 希 值 。 查 看 这 


个 提交 。 会 及 现 这 个 提交 没有 历史 提交 ， 是 我 们 需要 的 根据 交 。 





$ git 1og --pretty=raw 8f7f94b 

commit 8f7f94ba6a9d94ecc1c223aa4b311670599e1f86 

tree 3f9b9459e9c0532ff6e3c16c3098c947d55fba41 

author Jiang Xin <jiangxin@ossxp.com> 1292221037 +0800 

committer Jiang Xin <jiangxin@ossxp.com> 1292221037 +0800 
Commit from tree of tag A. 





另外 一 个 方法 是 使 用 git hash-object 命 令 ， 从 里 程 碑 A 指 向 的 提交 建 


立 一 个 根据 区 。 可 以 进行 如 下 操作 。 


(1) 查看 里 程 碑 A 指向 的 提交 。 


用 A^0 语 法 访问 里 程 碑 A 对 应 的 提交 。 





$ git cat-file commit A^Q 

tree 3f9b9459e9c0532ff6e3c16c3098c947d55fba41 

parent 63992f05a72865754809cc0772a9e1fbf134e380 

author Jiang Xin <jiangxin@ossxp.com> 1291704602 +0800 
committer Jiang Xin <jiangxin@ossxp.com> 1291704602 +0800 
README is from welcome.txt. 





(2) 将 上 面 的 输出 (里 程 碑 A 指 癌 的 提交 〉 过 小 掉 以 parent 开 尖 的 
行 ， 并 将 结果 保存 到 一 个 文件 中 。 





$ git cat-file commit A^0 | sed -e '/^parent/ d' > tmpfile 





(3) 运行 git hash-object 命 令 ， 将 文件 tmpfile 作 为 一 个 commit 对 象 
写 入 对 象 库 。 





$ git hash-object -t commit -w -- tmpfile 
4d387fd42a023aadcf0702907b848444e8c4429c 





(4) 上 面 执行 git hash-object 命 令 的 输出 结果 就 是 写 入 Git 对 象 库 中 
的 新 的 提交 对 象 ID。 但 看 会 发 现 该 提交 就 是 我 们 需要 的 新 的 根据 交 。 





$ git 1og --pretty=raw 4d387fd 

commit 4d387fd42a023aadcf0702907b848444e8c4429c 

tree 3f9b9459e9c0532ff6e3c16c3098c947d55fba41 

author Jiang Xin <jiangxin@ossxp.com> 1291704602 +0800 

committer Jiang Xin <jiangxin@ossxp.com> 1291704602 +0800 
README is from welcome.txt. 





无 论 采 用 哪 种 方法 创建 了 新 的 根据 交 后 ， 就 可 以 执行 变 基 操作 ， 将 
master 分 文 在 里 程 碑 A 之 后 的 提交 变 基 到 新 的 根据 区 上 。 下 面 的 示例 选 
择 第 一 种 方法 创建 的 根 提交 8f7f94b。 


(1) 执行 变 基 ， 将 master 分 支 里 程 碑 A 之 后 的 提交 全 部 迁移 到 根 提 
交 8f7f94b 上 。 





$ git rebase --onto 8f7f94b A master 

First, rewinding head to replay your work on top of it... 
Applying: Hello world initialized. 

Applying: ignore object files. 

Applying: add hello.h 

Applying: modify hello.h 








(2) 查看 日 志 看 到 当前 master 分 支 的 历史 已 经 精简 了 。 





$ git log --oneline --decorate 
2584639 (HEAD, master) modify hello.h 
30fe8b3 add hello.h 

4dd8a65 ignore object files. 

5f2cae1 Hello world initialized. 
8f7f94b Commit from tree of tag A. 








使 用 图 形 工具 得 看 提交 历史 ， 会 看 到 两 析 树 ， 如 岁 12-7 所 示 : 最 上 
面 的 一 梯 树 是 刚刚 通过 变 基 抛弃 了 大 部 分 历史 提交 的 新 的 master 分 文 ， 
下 面 的 一 株 树 则 是 变 基 前 的 提交 形成 的 。 下 面 的 一 棵 树 之 所 以 还 能 够 看 
到 ， 或 者 说 还 没有 从 版 本 库 中 彻 抵 清除 ， 是 因为 有 部 分 提交 仍 带 有 里 程 


人 碑 标 签 。 





Short Log Author Author Date 
[masterjmodify hello.h jiang Xin... 10-12-12 PM12:11 
add hello.h Jiang Xin... 10-12-7 PM7:39 
ignore object files. Jiang Xin... 10-12-7 PM7:21 
Hello world initialized. Jiang Xin... 10-12-7 PM6:33 
Commit from tree of tag A. Jiang Xin... 10-12-13 PM2:17 
modify hello.h Jiang Xin... 10-12-12 PM12:11 
[Ej]add hello.h Jiang Xin... 10-12-7 PM7:39 
[D] move .gitignore outside also works. Jiang Xin... 10-12-7 PM7:34 


ignore object files. Jiang Xin... 10-12-7 PM7:21 
Hello world initialized. Jiang Xin... 10-12-7 PM6:33 
[A|]README is from welcome txt. Jiang Xin... 10-12-7 PM2:50 
restore file: welcome txt Jiang Xin... 10-12-7 PM2:32 
delete trash files. (using: git add -u) Jiang Xin... 10-12-7 PM2:02 
WIP on master: 2b31c19 Merge commit 'acc2f69' jiang Xin... 10-12-7 AM11:53 
index on master: 2b31c19 Merge commit 'acc2f69' Jiang Xin... 10-12-7 AM11:53 
[old practice] Merge commit 'acc2f69' Jiang Xin... 10-12-5 PM3:51 
commit in detached HEAD mode. Jiang Xin... 10-12-5 PM3:43 
does master follow this new commit? Jiang Xin... 10-12-4 PM12:13 
which version checked in? Jiang Xin... 10-11-29 PM5:23 
who does commit? Jiang Xin... 10-11-29 AM11:00 
initialized. Jiang Xin... 10-11-28 PM12:48 





图 12-7 丢弃 历史 后 的 提交 分 支 图 


12.5 反 转 提交 


前 面 介绍 的 操作 都 涉及 对 历史 的 修改 ， 这 对 于 一 个 人 使 用 Git 没 有 
问题 ， 但 是 如 果 多 人 协同 就 会 有 问题 了 。 多 人 协同 使 用 Git， 在 本 地 厂 
本 库 做 的 提交 会 通过 多 人 之 间 的 交互 成 为 他 人 版 本 库 的 一 部 分 ， 更 改 历 
史 操 作 只 能 是 针对 自己 的 版 本 库 ， 而 无 法 去 修改 他 人 的 版 本 库 ， 正 所 
谓 “ 用 水 难 收 *"。 在 这 种 情况 下 要 想 修正 一 个 错误 历史 提交 的 正确 做 法 是 
反 转 提交 ， 即 重新 做 一 次 新 的 提交 ， 相 当 于 用 错误 的 历史 提交 的 反问 提 
交 ， 来 修正 错误 的 历史 提交 。 








Git 反 问 提 交 命 令 是 : git revert， 下 面 在 DEMO 版 本 库 中 实践 一 下 。 
注意 : Subversion 的 用 户 不 要 想当然 地 和 svn revert 命 令 对 应 ， 这 两 个 版 
本 控制 系统 中 revert 命 令 的 功能 完全 不 相干 。 


当前 DEMO 版 本 库 最 新 的 提交 包含 如 下 改动 : 





$ git show HEAD 
commit 25846394defe16eab103b92efdaab5e46cc3dc22 
Author: Jiang Xin <jiangxin@ossxp.com> 
Date: Sun Dec 12 12:11:00 2010 +0800 
modify hello.h 
diff --git a/README b/README 
index 51dbfd2, ,ceaf01b 100644 
-- a/README 
+++ b/README 
@Q -1, 3 +1, 4 @@ 
Hello. 
Nice to meet you. 
Bye-Bye. 
+Wait... 
diff --git a/src/hello.h b/src/hello.h 
index ©0043c3b. .6e482c6 100644 


--- a/src/hello.h 
+++ b/src/hello.h 
@@ -1 +1, 2 @@ 

/* test */ 
+/* end */ 





在 不 改变 这 个 提交 的 前 提 下 撤销 对 其 的 修改 ， 就 需要 用 到 git revert 
反 转 提交 。 





$ git revert HEAD 





运行 该 命令 相当 于 将 HEAD 提 交 反 加 再 提交 一 次 ， 在 提交 说 明 编辑 
状态 下 暂停， 显示 如 下 《注释 行 被 名 略 ) : 





Revert "modify hello.h" 
This reverts commit 25846394defe16eab103b92efdaab5e46cc3dc22 . 





可 以 在 编辑 器 中 修改 提交 说 明 ， 提 交 说 明 编 辑 完 毕 保 存 退 出 则 完成 
反 转 提交 。 得 看 提交 日 志 可 以 看 到 新 的 提交 相当 于 所 撤销 提交 的 反 辐 提 


一 
人 人 入 
O 





$ git 1og --stat -2 
commit 6e6753add1601c4efa7857ab4c5b245e0e161314 
Author: Jiang Xin <jiangxin@ossxp.com> 
Date: Mon Dec 13 15:19:12 2010 +0800 
Revert "modify hello.h" 
This reverts commit 25846394defe16eab103b92efdaab5e46cc3dc22 ， 
README | . 
src/hello.h | 1 - 
2 files changed, © insertions(+), 2 deletions(-) 
commit 25846394defe16eab103b92efdaab5e46cc3dc22 
Author: Jiang Xin <jiangxin@ossxp.com> 
Date: Sun Dec 12 12:11:00 2010 +0800 
modify hello.h 
README | 
src/hello.h | 
2 files changed, 2 insertions(+), 0 deletions(-) 


Bl 
1+ 


[ee | 


第 13 章 ” Git 克 隆 


到 现在 为 止 ， 大 家 已 经 领略 到 Git 的 灵活 性 和 健壮 性 。Git 可 以 通过 
重 置 随意 撤销 提交 ， 可 以 通过 变 基 操 作 更 改 历 史 ， 可 以 随意 重组 提交 ， 
还 可 以 通过 reflog 的 记录 纠正 错误 的 操作 。 但 是 再 健壮 的 版 本 库 设 计 ， 
也 抵挡 不 了 存储 介质 的 骨 沉 。 还 有 一 点 束 古 不 要 起 了 Git 版 本 库 是 哄 在 
工作 区 根 目录 下 的 .git 目 录 中 ， 如 果 起 了 这 一 反 直 接 删 除 工作 区 ， 就 会 
把 版 本 库 也 同时 删 挥 ， 塌 剧 就 此 友和 生 。 














“不 要 把 鸡 皇 装 在 一 个 篮子 里 ”是 颠 扑 不 破 的 安全 法 则 。 


在 本 章 会 学 习 到 如 何 使 用 git clone 命 令 建 并 版 本 库 克 隆 ， 以 及 如 何 


使 用 git push 和 git pull 命 令 实 现 克 隆之 间 的 同步 。 


13.1 鸡蛋 不 装 在 一 个 篮子 里 


Git 的 版 本 库 目 录 和 工作 区 在 一 起 ， 因 此 存在 一 损 俱 损 的 问题 ， 即 
如 果 删 除 一 个 项 目的 工作 区 ， 同 时 也 会 把 这 个 项 目的 版 本 库 删 除 挥 。 一 
个 项 目 仅 在 一 个 工作 区 中 维护 太 和 危险 了 ， 如 果 有 两 个 工作 区 融会 好 很 





A B 
Qs Push (DD: PULL 
OO UL © : PUSH 


图 13-1 克隆 版 本 库 关系 图 


图 13-1 中 一 个 项 目 使 用 了 两 个 版 本 库 进 行 维护 ， 两 个 版 本 库 之 间 通 
过 PULL 和 /或 PUSH 操 作 实 现 同 步 : 


* 版 本 库 A 通 过 克隆 操作 创建 克隆 版 本 库 B。 


` 版 本 库 A 可 以 通过 PUSH (推送 ) 操作 ， 将 新 提交 传递 给 版 本 库 


` 版 本 库 A 可 以 通过 PULL ( 拉 回 ) 操作 ， 将 版 本 库 B 中 的 新 提交 拉 
回 到 自身 (A) 。 


. 版 本 库 B 可 以 通过 PULL ( 拉 回 ) 操作 ， 将 版 本 库 A 中 的 新 提交 拉 
回 到 自身 (B) 。 


. 版 本 库 B 可 以 通过 PUSH (推送 ) 操作 ， 将 新 提交 传递 给 版 本 库 


Git 使 用 git clone 命 令 实现 版 本 库 殉 隆 ， 主 要 有 如 下 三 种 用 法 : 











用 法 1: git clone <repository> <directory> 
用 法 2: git clone --bare <repository> <directory.git> 
用 法 3: git clone --mirror <repository> <directory.git> 



































这 三 种 用 法 的 区 别 如 下 : 


` 用 法 1 将 指向 的 版 本 库 创 建 一 个 克隆 到 目录 。 目 录 相 当 于 克隆 版 
本 库 的 工作 区 ,文件 都 会 检 出 ， 版 本 库 位 于 工作 区 下 的 .git 目 录 中 。 


“ 用 法 2 和 用 法 3 创建 的 克隆 版 本 库 都 不 包含 工作 区 ， 直 接 就 是 版 本 
库 的 内 容 ， 这 样 的 版 本 库 称 为 裸 版 本 库 。 一 般 约 定 俗 成 裸 版 本 库 的 目录 
名 以 .git 为 后 级 ， 所 以 上 面 示例 中 将 克隆 出 来 的 神 版 本 库 目 录 名 写作 。 


. 用 法 3 区 别 于 用 法 2 之 处 在 于 用 法 3 克隆 出 来 的 裸 版 本 对 上 游 版 本 


库 进行 了 注册 ， 这 样 可 以 在 裸 版 本 库 中 使 用 git fetch 命 令 和 上 游 版 本 库 进 
行 持 续 同 步 。 


用 法 3 只 在 1.6.0 或 更 新 版 本 的 Git 中 才 提 供 。 


Git 的 PUSH 和 PULL 命 令 的 用 法 相似 ， 使 用 下 面 的 语法 : 





git push [<remote-repos> [<refspec>]] 
git pull [<remote-repos> [<refspec>]] 








其 中 方 括号 的 含义 是 参数 可 以 省 略 ，<remote-repos> 是 远程 版 本 库 
的 地 址 或 名 称 ，<refspec> 是 引用 表达 式 ， 暂 时 理解 为 引用 即 可 。 后 面 的 
章节 再 具体 介绍 PUSH 和 PULL 命 令 的 细节 。 





下 面 就 通过 不 同 的 Git 命 令 组 合 ， 党 握 版 本 库 殉 隆 和 镜像 的 技巧 。 


13.2 ”对 等 工作 区 





不 使 用 --bare 或 --mirror 创 建 出 来 的 克隆 包含 工作 区 ， 这 样 束 会 产生 
两 个 包含 工作 区 的 版 本 库 。 这 两 个 版 本 库 是 对 等 的 ， 如 图 13-2 所 示 。 








A 工作 区 B 工作 区 
git clone 





A B( 备 份 ) 
图 13-2” 带 工作 区 的 对 等 版 本 库 


这 两 个 工作 区 本 质 上 没有 区 别 ， 但 是 往往 提交 是 在 一 个 版 本 〈A) 
中 进行 的 ， 另 外 一 个 〈B) 作为 备份 。 对 于 这 种 对 等 工作 区 模式 ， 版 本 
库 的 同步 只 有 一 种 可 行 的 操作 模式 ， 就 是 备份 库 〈B) 执行 git pull 命 令 
从 源 版 本 库 (A) 中 拉 回 新 的 提交 实现 版 本 库 同步 。 为 什么 不 能 从 版 本 
库 A 回 版 本 库 B 执 行 git push 推 送 操作 呢 ? 看 看 下 面 的 操作 。 





执行 克隆 命令 ， 将 版 本 库 /path/to/my/workspace/demo 克 隆 


到 /path/to/my/workspace/demo-backup。 


$ git clone /path/to/my/workspace/demo /path/to/my/workspace/demo-backup 
Cloning into /path/to/my/workspace/demo-backup... 
done. 





进入 demo 版 本 库 ， 生 成 一 些 测试 提交 使 用 --allow-empty 参 数 可 以 
生成 空 提交 





$ cd /path/to/my/workspace/demo/ 

$ git commit --allow-empty -m "sync test 1" 
[master 790e72a] Sync test 1 

$ git commit --allow-empty -m "sync test 2" 
[master f86b7bf] sync test 2 





能 够 在 demo 版 本 库 向 demo-backup 版 本 库 执 行 PUSH 操作 吗 ? 执行 
一 下 git push 看 一 看 。 





$ git push /path/to/my/workspace/demo-backup 
Counting objects: 2, done. 
Delta compression using up to 2 threads. 
Compressing objects: 100% (2/2), done. 
Writing objects: 100% (2/2), 274 bytes, done. 
Total 2 (delta 1), reused 0 (delta 0) 
Unpacking objects: 100% (2/2), done. 
remote: error: refusing to update checked out branch: refs/heads/master 
remote: error: By default, updating the current branch in a non-bare repository 
remote: error: is denied, because it will make the index and work tree inconsistent 
remote: error: with what you pushed, and will require 'git reset --hard' to match 
remote: error: the work tree to HEAD. 
remote: error: 
remote: error: You can set 'receive.denyCurrentBranch' configuration variable to 
remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into 
remote: error: its current branch; however, this is not recommended unless you 
remote: error: arranged to update its work tree to match what you pushed in some 
remote: error: other way. 
remote: error: 
remote: error: To squelch this message and still keep the default behaviour, set 
remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'. 
To /path/to/my/workspace/demo-backup 

! [remote rejected] master -> master (branch is currently checked out) 
error: failed to push some refs to '/path/to/my/workspace/demo-backup' 





翻译 成 中 文 : 





$ git push /path/to/my/workspace/demo-backup 


对 方 说 ; 错 了 : 
拒绝 更 新 已 检 出 的 分 支 refs/heads/master 。 
默认 更 新 非 裸 版 本 库 的 当前 分 支 是 不 被 允许 的 ， 因 为 这 将 会 导致 
和 暂 存 区 和 工作 区 与 你 推送 至 版 本 库 的 新 提交 不 一 致 。 这 太古 怪 了 。 
如 果 您 一 意 孤 行 ， 也 不 是 不 允许 ， 但 是 你 需要 为 我 设置 如 下 参数 : 

receive.denyCurrentBranch = ignore|warn 

到 /path/to/my/workspace/demo-backup 

! [对 方 拒绝 ] master -> master (分 支 当 前 已 检 出 ) 

错误 : 部 分 引用 的 推送 失败 了 ， 至 '/path/to/my/workspace/demo-backup' 





































































































从 错误 输出 中 可 以 看 出 ， 虽 然 可 以 改变 Git 的 默认 行为 ， 允 许 同 工 
作 区 推送 已 经 检 出 的 分 文 ， 但 是 这 么 做 实在 不 高 明 。 


为 了 实现 同步 ， 需 要 进入 到 备份 版 本 库 中 ， 执 行 git pull 命 令 。 





$ git pull 
From /path/to/my/workspace/demo 
6e6753a..f86b7bf master -> origin/master 
Updating 6e6753a..f86b7bf 
Fast-forward 





在 demo-backup 版 本 库 中 查看 提交 日 志 ， 可 以 看 到 在 demo 版 本 库 中 
的 新 提交 已 经 被 拉 回 到 demo-backup 版 本 库 中 。 





$ git 1og --oneline -2 
f86b7bf Sync test 2 
790e72a Sync test 1 





为 什么 执行 git pull 命 令 没 有 像 执行 git push 命 令 那样 提供 那么 多 的 参 
数 呢 ? 这 是 因为 在 执行 git clone 操 作 后 ， 克 隆 出 来 的 demo-backup 版 本 库 
中 对 源 版 本 库 (上 游 版 本 库 ) 进行 了 注册 ， 所 以 在 demo-backup 版 本 库 
中 执行 拉 回 操作 ， 无 须 设置 上 游 版 本 库 的 地 址 。 





在 demo-backup 版 本 库 中 可 以 使 用 下 面 的 命令 但 看 对 上 游 版 本 库 的 
注册 信息 : 





$ cd /path/to/my/workspace/demo-backup 

$ git remote -v 

origin /path/to/my/workspace/demo (fetch) 
origin /path/to/my/workspace/demo (push) 








实际 上 ， 注 册 上 游 远 程 版 本 库 的 奥秘 都 在 Git 的 配置 文件 中 上 略 去 
无 关 的 行 ) : 





$ cat /path/to/my/workspace/demo-backup/ .git/config 


[remote "origin"] 
fetch = +refs/heads/*:refs/remotes/origin/* 
url = /path/to/my/workspace/demo 
[branch "master"] 
remote = origin 
merge = refs/heads/master 











关于 配置 文件 remote] 小 节 和 [branch] 小 节 的 奥秘 将 在 第 3 篇 第 19 章 
中 予以 介绍 。 





13.3 ”克隆 生成 裸 版 本 库 


上 一 节 在 对 等 工作 区 模式 下 ， 工 作 区 之 间 执 行 推送 ， 可 能 会 引发 大 
段 的 错误 输出 ， 如 果 采 用 裸 厂 本 库 则 没有 相应 的 问题 。 这 是 因为 裸 版 本 
库 没 有 工作 区 。 没 有 工作 区 还 有 一 个 好 处 就 是 空间 占用 会 更 小 。 


A 工作 区 





A B.git 
图 13-3 ”从 版 本 库 中 克隆 裸 版 本 库 


如 图 13-3 所 示 ， 使 用 --bare 参 数 将 demo 版 本 库 克隆 
到 /path/to/repos/demo.git， 然 后 就 可 以 从 demo 版 本 库 问 克隆 的 裸 版 本 库 
执行 推送 操作 了 。 (为 了 说 明 方 便 ， 使 用 了 /path/to/repos/ 作 为 Git 裸 版 本 
的 根 路 径 ， 在 后 面 的 章节 中 这 个 目录 也 将 作为 Git 服 务 器 端 版 本 库 的 根 
路 径 。 可 以 在 磁盘 中 以 root 账 户 创建 该 路 径 并 设置 正确 的 权限 。) 





$ git clone --bare /path/to/my/workspace/demo /path/to/repos/demo.git 
Cloning into bare repository /path/to/repos/demo.git... 
done. 








克隆 出 来 的 /path/to/repos/demo.git 目 录 就 是 版 本 库 目 录 ， 不 包含 工 
作 区 :。 


. 看 看 /path/to/repos/demo.git 目 录 的 内 容 。 





$ 1s -F /path/to/repos/demo.git 
branches/ config description HEAD hooks/ info/ objects/ packed-refs refs/ 





. 还 可 以 看 到 demo.git 版 本 库 中 core.bare 的 配置 为 true。 





$ git --git-dir=/path/to/repos/demo.git config core.bare 
true 





进入 demo 版 本 亩 ， 生 成 一 些 测试 提交 。 





$ cd /path/to/my/workspace/demo/ 

$ git commit --allow-empty -m "sync test 3" 
[master d4b42b7] sync test 3 

$ git commit --allow-empty -m "sync test 4" 
[master ©0285742] Sync test 4 





在 demo 版 本 库 向 demo-backup 版 本 库 执行 PUSH 操 作 ， 还 会 有 错误 
吗 ? 


` 不 带 参数 执行 git push， 因 为 未 设 定 上 游 远 程 版 本 库 ， 因 此 会 报 





$ git push 
fatal: No destination configured to push to. 





` 在 执行 git push 时 使 用 /path/to/repos/demo.git 作 为 参数 。 推 送 成 
功 。 





$ git push /path/to/repos/demo.git 
Counting objects: 2, done. 
Delta compression using up to 2 threads. 
Compressing objects: 100% (2/2), done. 
Writing objects: 100% (2/2), 275 bytes, done. 
Total 2 (delta 1), reused 0 (delta 0) 
Unpacking objects: 100% (2/2), done. 
To /path/to/repos/demo.git 

f86b7bf..0285742 master -> master 





看 看 demo.git 版 本 库 ， 是 否 已 经 完成 了 同步 





$ git --git-dir=/path/to/repos/demo.git 10og --oneline -2 
0285742 Sync test 4 
d4b42b7 Sync test 3 








这 个 方式 实现 版 本 库 本 地 镜像 显然 是 更 好 的 方法 ， 因 为 可 以 直接 在 
工作 区 修改 和 提交 ， 然 后 执行 git push 命 令 实现 推送 。 舟 有 一 点 遗憾 的 是 
推送 命令 还 需要 加 上 裸 版 本 库 的 路 径 。 这 个 遗憾 在 第 3 篇 第 19 章 会 给 出 
解决 方案 。 








13.4 创建 生成 裸 版 本 库 


裸 版 本 库 不 但 可 以 通过 克隆 的 方式 创建 ， 还 可 以 通过 git init 命 令 以 
初始 化 的 方式 创建 。 之 后 的 同步 方式 和 上 一 市 大 同 小 异 ， 如 图 13-4 所 


让 
pp 
O 






git init --bare 


A 工作 区 


忆 圈 


A B.git 
图 13-4 ”向 裸 版 本 库 推 送 






命令 git init 在 “第 4 章 Git 初 始 化 ”一 章 束 已 经 用 到 了 ， 是 用 于 初始 化 
一 个 版 本 库 的 。 之 前 执行 git init 命 令 初 始 化 的 版 本 库 是 带 工作 区 的 ， 如 
何以 裸 版 本 库 的 方式 初始 化 一 个 版 本 库 呢 ?奥秘 就 在 于 --bare 参 数 。 


下 面 的 命令 会 在 目录 /path/to/repos/demo-init.git 中 创建 一 个 空 的 裸 版 
本 库 。 


$ git init --bare /path/to/repos/demo-init.git 


Initialized empty Git repository in /path/to/repos/demo-init.git/ 








创建 的 果真 是 课 版 本 库 吗 ? 


. 看 看 /path/to/repos/demo-init.git 下 的 内 容 : 





$ ls -F /path/to/repos/demo-init.git 
branches/ config description HEAD hooks/ info/ objects/ refs/ 





. 看 看 这 个 版 本 库 的 配置 core.bare 的 值 : 





$ git --git-dir=/path/to/repos/demo-init.git config core.bare 
true 








是 空 版 本 库 没 有 内 容 啊 ， 那 就 执行 PUSH 操作 为 其 创建 内 容 鹃 。 





$ cd /path/to/my/workspace/demo 

$ git push /path/to/repos/demo-init.git 

No refs in common and none specified; doing nothing. 

Perhaps you should specify a branch such as 'master ' ， 

fatal: The remote end hung up unexpectedly 

error: failed to push some refs to '/path/to/repos/demo-init.git'" 





为 什么 出 错 了 ? 翻译 一 下 错误 输出 。 





$ cd /path/to/my/workspace/demo 

$ git push /path/to/repos/demo-init.git 

没有 指定 要 推送 的 引用 ， 而 且 两 个 版 本 库 也 没有 共同 的 引用 。 
所 以 什么 也 没有 做 。 
可 能 您 需要 提供 要 推送 的 分 文 名 ， 如 "master '。 
疡 重 销 误 ; 远程 操作 意外 终 ] 
着 误 : 部 分 引用 推送 失败 ， 至 '/path/to/repos/demo-init.git' 
















































































关于 这 个 问题 的 详细 说 明 要 在 第 3 篇 第 19 章 “19.4PUSH 和 PULL 操 作 





和 远程 版 本 库 ? 小 节 中 介绍 ， 这 里 先 说 一 个 省 略 版 : 因 

为 /path/to/repos/demo-init.git 版 本 库 刚刚 初始 化 完成 ， 还 没有 任何 提交， 
更 不 要 说 分 文 了 。 当 执行 git push 命 令 时 ， 如 果 没 有 设 定 推 送 的 分 文 ， 而 
且 当 前 分 文 也 没有 注册 到 远程 的 茶 个 分 文 ， 将 检查 远程 分 文 是 否 有 和 本 
地 相同 的 分 文 名 《如 master) ， 如 果 有 ， 则 推送 ， 人 否则 报错 。 








所 以 需要 把 git push 命 令 写 得 再 完整 一 些 。 像 下 面 这 样 操作 ， 就 可 以 
完成 向 空 的 裸 版 本 库 的 推送 。 





$ git push /path/to/repos/demo-init.git master:master 
Counting objects: 26, done. 
Delta compression using up to 2 threads. 
Compressing objects: 100% (20/20), done. 
Writing objects: 100% (26/26), 2.49 KiB, done. 
Total 26 (delta 8), reused 0 (delta 0) 
Unpacking objects: 100% (26/26), done. 
To /path/to/repos/demo-init.git 
* [new branch] master -> master 





上 面 的 git push 命 令 也 可 以 简写 为 : git push/path/to/repos/demo- 


init.git master。 


推送 成 功 了 吗 ? 看 看 demo-init.git 版 本 库 中 的 提交 。 





$ git --git-dir=/path/to/repos/demo-init.git log --oneline -2 
©0285742 Sync test 4 
d4b42b7 sync test 3 





好 了 继续 在 demo 中 执行 几 次 提交 。 





$ cd /path/to/my/workspace/demo/ 
$ git commit --allow-empty -m "sync test 5" 


[master 424aa67] Sync test 5 
$ git commit --allow-empty -m "Sync test 6" 
[master 70a5aa7] Sync test 6 





然后 再 问 demo-init.git 推 送 。 注 意 这 次 使 用 的 命令 。 





$ git push /path/to/repos/demo-init.git 

Counting objects: 2, done. 

Delta compression using up to 2 threads. 

Compressing objects: 100% (2/2), done. 

Writing objects: 100% (2/2), 273 bytes, done. 

Total 2 (delta 1), reused 0 (delta 0) 

Unpacking objects: 100% (2/2), done. 

To /path/to/repos/demo-init.git 
0285742..70a5aa7 master -> master 





为 什么 这 次 使 用 git push 命 令 后 面 没 有 跟 上 分 支 名 呢 ? 这 是 因为 远程 
版 本 库 (demo-init.git〉 中 已 经 不 再 是 空 版 本 库 了 ， 有 名 为 master 的 分 
区 








通过 下 面 的 命令 可 以 但 看 远程 版 本 库 的 分 文 。 





$ git ls-remote /path/to/repos/demo-init.git 
70a5aa7a7469076fd435a9e4f89c4657ba603ced HEAD 
70a5aa7a7469076fd435a9e4f89c4657ba603ced refs/heads/master 





至 此 相信 您 已 经 能 够 把 鸡蛋 放 在 不 同 的 篮子 中 了 ， 也 对 使 用 Git 更 
加 有 信心 了 吧 。 


第 14 章 ”Git 库 管理 





版 本 库 管 理 ? 那 不 是 管理 员 要 干 的 事情 么 ， 怎 么 放 在 “Git 独 雪 ” 这 一 


部 分 了 ? 





没有 错 ， 这 是 因为 对 于 Git， 每 个 用 户 都 是 自己 版 本 库 的 管理 员 ， 
所 以 在 “Git 独 和 ”的 最 后 一 章 ， 我 们 来 谈 一 谈 Git 版 本 库 管 理 的 问题 。 如 
果 下 面 的 问题 您 没有 过 到 或 不 感 兴趣 ， 大 可 以 放心 地 跳 过 这 一 章 。 











. 从 网 上 克隆 来 的 版 本 库 ， 为 什么 对 象 库 中 找 不 到 对 象 文件 ? 而且 
引用 目录 里 也 看 不 到 所 有 的 引用 文件 ? 


不 小 心 添加 了 一 个 大 文件 到 Git 库 中 ， 用 重 置 命令 丢弃 了 包含 大 
文件 的 提交 ， 可 是 版 本 库 不 见 小 ， 大 文件 仍 在 对 象 库 中 。 


` 本 地 版 本 库 的 对 象 库 里 的 文件 越 来 越 多 ， 这 可 能 导致 Git 性 能 的 
降低 。 





14.1 对 象 和 引用 哪里 去 了 





从 Github 上 克隆 一 个 示例 版 本 库 ， 这 个 版 本 库 在 “第 11 章 历史 和 罕 
梭 ” 一 半 就 已 经 元 隆 过 一 次 了， 现在 要 重新 克隆 一 份 。 为 了 和 原来 的 殉 
隆 相 区 别 ， 我 们 将 元 隆 到 男 外 的 目录 。 执 行 下 面 的 命令 。 





$ cd /path/to/my/workspace/ 

$ git clone git://github.com/ossxp-com/gitdemo-commit-tree.git i-am-admin 
Cloning into i-am-admin... 

remote: Counting objects: 65, done. 

remote: Compressing objects: 100% (53/53), done. 
remote: Total 65 (delta 8), reused 0 (delta 0) 
Receiving objects: 100% (65/65), 78.14 KiB | 42 KiB/s, 
Resolving deltas: 100% (8/8), done. 


done. 





进入 克隆 的 版 本 库 ， 使 用 git show-ref 命 令 看 看 所 包含 的 引用 。 





$ cd /path/to/my/workspace/i-am-admin 
$ git show-ref 


6652aQdce6a5067732c00ef0a220810a7230655e 
6652aQdce6a5067732c00ef0a220810a7230655e 
6652aQdce6a5067732c00ef0a220810a7230655e 
c9b03a208288aebdbfe8d84aeb984952a16da3f2 
1a87782f8853c6e11aacba463af04b4fa8565713 
9f8b51bc7dd98f7501ade526dd78c55ee4abb75f 
887113dc095238a0f4661400d33ea570e5edc37c 
6decdoad3201ddb3f5b37c201387511059ac120c 
70cab20f099e0af3f870956a3fbbbda50a17864f 
96793e37c7f1ic7b2ddf69b4cie252763c11a711f 
476e74549047e2c5fbd616287a499cc6f07ebde0 
76945a15543c49735634d58169b349301d65524d 
f199c10c3f1a54fa3f9542902b25b49d58efb35b 


refs/heads/master 
refs/remotes/origin/HEAD 
refs/remotes/origin/master 
refs/tags/A 

refs/tags/B 

refs/tags/CcC 

refs/tags/D 

refs/tags/E 

refs/tags/F 

refs/tags/6 

refs/tags/H 

refs/tags/I 

refs/tags/yJ 





其 中 以 refsmheads/ 开 头 的 是 分 文 ; 
库 分 文 在 本 地 的 映射 ， 这 会 在 后 面 的 章节 中 介绍 ; 


以 refs/remotes/ 开 头 的 是 远程 版 本 
以 refs/tags/ 开 头 的 是 





里 程 碑 。 按 照 之 前 的 经 验 ， 在 .git/refs 目 录 下 应 该 有 这 些 引 用 所 对 应 的 文 


件 才 是 。 看 看 都 在 么 ? 





$ find .git/refs/ -type f 
.git/refs/remotes/origin/HEAD 
.git/refs/heads/master 








为 什么 才 有 两 个 文件 ? 实际 上 当 运 行 下 面 的 命令 后 ， 引 用 目录 下 的 
人 作 会 更 洗 : 





$ git pack-refs --all 
$ find .git/refs/ -type f 
.git/refs/remotes/origin/HEAD 





么 本 应 该 出 现在 .gitrefs/ 目 录 下 的 引用 文件 都 到 哪里 去 了 呢 ? 答 
案 是 这 些 文 件 被 打包 了 ， 放 到 一 个 文本 文件 .gitpacked-refs 中 了 。 碍 看 
一 下 这 个 文件 中 的 内 容 。 





$ head -5 .git/packed-refs 

# pack-refs with: peeled 

6652a0dce6a5067732c00ef0a220810a7230655e refs/heads/master 
6652a0dce6a5067732c00ef0a220810a7230655e refs/remotes/origin/master 
c9b03a208288aebdbfe8d84aeb984952a16da3f2 refs/tags/A 
^A81993234fc12a325d303eccea20f6fd629412712 





再 来 看 看 Git 的 对 象 (commit、blob 、tree、tag) 在 对 象 库 中 的 存 
储 。 通 过 下 面 的 命令 ， 会 发 现 对 象 库 也 不 是 原来 熟悉 的 模样 了 。 





$ find .git/objects/ -type f 
.git/objects/pack/pack-969329578b95057b7ea1208379a22c250c3b992a.idx 
.git/objects/pack/pack-969329578b95057b7ea1208379a22c250c3b992a.pack 








对 象 库 中 只 有 两 个 文件 ， 本 应 该 一 个 一 个 独立 保存 的 对 象 都 不 见 


了 。 您 应 该 能 够 猜 到 ， 所 有 的 对 象 文 件 都 被 打包 到 这 两 个 文件 中 了 ， 其 
中 以 .pack 结 尾 的 文件 是 打包 文件 ， 以 .idx 结 尾 的 是 索引 文件 。 打 包 文 件 
和 对 应 的 索引 文件 只 是 扩展 名 不 同 ， 都 保存 于 .gityobjects/pack/ 目 录 下 。 
Git 对 于 以 SHA1 哈 希 值 作为 目录 名 和 文件 名 保存 的 对 象 有 一 个 术语 ， 称 
为 松散 对 象 。 松 散 对 象 打包 后 会 提高 访问 效率 ， 而 且 不 同 的 对 象 可 以 通 
过 增 量 存储 节省 磁盘 空间 。 

















通过 Git 一 个 砌 层 的 命令 可 以 查看 索引 中 包含 的 对 象 : 


$ git show-index < .git/objects/pack/pack-*.idx | head -5 
661 0cd7f2ea245d90d414e502467ac749f36aa32cc4 (0793420b) 

63020 1026d9416d6fc8d34e1ledfb2bc58adb8aa5a6763 (ed77ff72) 
3936 15328fc6961390b4b10895f39bb042021eddo7ea (13fb79ef ) 
3768 1a588ca36e25f58fbeae421c36d2c39e38e991ef (86e3bobd ) 
2022 1a87782f8853c6e11aacba463af04b4fa8565713 (e269ed74) 





为 什么 克隆 远程 版 本 库 束 可 以 产生 对 象 库 打包 及 引用 打包 的 效果 
昵 ? 这 是 因为 克隆 远程 版 本 库 时 ， 使 用 了 “智能 ”的 通信 协议 ， 远 程 Git 服 
务 嚣 将 对 象 打 包 后 传输 给 本 地 ， 形 成 本 地 版 本 库 的 对 象 库 中 的 一 个 包含 
所 有 对 象 的 包 及 索引 文件 。 无 疑 这 样 的 传输 方式 一 一 按 需 传输 、 打 包 传 


和 输 一 一 效率 最 高 。 











区 隆之 后 的 版 本 库 在 日 营 的 提交 中 ， 产 生 的 新 对 象 仍旧 以 松散 对 象 
存在 ， 而 不 是 以 打包 的 形式 ， 日积月累 会 在 本 地 版 本 库 的 对 象 库 中 形成 
大 量 的 松散 文件 。 松 散 对 象 只 是 进行 了 压缩 ， 而 没有 打包 文件 才 有 
的 ) 增 量 存储 的 功能 ， 会 浪费 磁盘 空间 ， 也 会 降低 访问 效率 。 更 为 严重 








的 是 一 些 非 正 式 的 临时 对 象 〈 暂 存 区 操作 中 产生 的 临时 对 象 ) 也 以 松散 
对 象 的 形式 保存 在 对 象 库 中 ， 造 成 磁盘 空间 的 浪费 。 下 一 市 就 着 手 处 理 
临时 对 象 的 问题 。 





14.2 ”上 暂 存 区 操作 引入 的 临时 对 和 象 





暂 存 区 操作 有 可 能 在 对 象 库 中 产生 临时 对 象 ， 例 如 ， 文 件 反 复 地 修 
改 、 反 复 地 向 蜀 存 区 添加 ， 或 者 添加 到 和 暂 存 区 后 不 提交 甚至 直接 撤销 ， 
天 会 产生 垃圾 数据 占用 磁盘 空间 。 为 了 说 明 临 时 对 象 的 问题 ， 需 要 准备 
一 个 大 的 压缩 文件 ，10MB 即 可 。 

在 Linux 上 与 内 核 匹 配 的 initrd 文 件 〈 内 核 启 动 加 载 的 内 存盘 ) 就 是 


一 个 大 的 压缩 文件 ， 可 以 用 于 此 节 的 示例 。 将 大 的 压缩 文件 放 在 版 本 库 
外 的 一 个 目录 上 ， 因 为 这 个 文件 会 多 次 用 到 。 





$ cp /boot/initrd,img-2.6.32-5-amd64 /tmp/bigfile 
$ du -sh /tmp/bigfile 
11M /tmp/bigfile 


将 这 个 大 的 压缩 文件 复制 到 工作 区 中 ， 复 制 两 份 。 





$ cd /path/to/my/workspace/i-am-admin 
$ cp /tmp/bigfile bigfile 
$ cp /tmp/bigfile bigfile.dup 





然后 将 工作 区 中 两 个 内 容 完 全 一 样 的 大 文件 加 入 和 暂 存 区 。 


$ git add bigfile bigfile.dup 


查看 一 下 磁盘 空间 占用 : 


` 工作 区 连同 版 本 库 共 占 用 33MB。 





$ du -sh . 
33M 





. 其 中 版 本 库 只 占用 了 11MB。 版 本 库 空间 占用 是 工作 区 的 一 半 。 


如 果 再 有 谁 说 版 本 库 空 间 占 用 一 定 比 工作 区 大 ， 可 以 用 这 个 例子 回 
击 他 。 





$ du -sh .git/ 
11M .git/ 











看 看 版 本 库 中 对 象 库 内 的 文件 ， 会 发 现 多 出 了 一 个 松散 对 象 。 之 所 
以 添加 两 个 文件 而 只 有 一 个 松散 对 象 ， 是 因为 Git 对 于 文件 的 保存 是 将 
内 容 保 存 为 blob 对 象 中 ， 和 文件 名 无 关 ， 相 同 内 容 的 不 同文 件 会 共享 同 
一 个 blob 对 象 。 





$ find .git/objects/ -type f 
.git/objects/2e/bcd92dodda2bad50c775dc662c6cb700477aff 
.git/objects/pack/pack-969329578b95057b7ea1208379a22c250c3b992a.idx 
.git/objects/pack/pack-969329578b95057b7ea1208379a22c250c3b992a.pack 








如 琳 不 想 提 交 ， 想 将 文件 搬出 暂 存 区 ， 则 进行 如 下 操作 。 


(1) 俘 看 当前 暂 存 区 的 状态 。 








$ git status -s 
A bigfile 
A bigfile.dup 





(2) 将 添加 的 文件 撤 出 暂 存 区 。 


$ git reset HEAD 


(3) 通过 查看 状态 ， 看 到 文件 被 撤 出 暂 存 区 了 。 





$ git status -s 
?? bigfile 
?? bigfile.dup 





文件 撤 出 暂 存 区 后 ， 在 对 象 库 中 产生 的 blob 松 散 对 象 仍然 存在 ， 通 
过 查看 版 本 库 的 磁盘 占用 残 可 以 看 出 来 。 


$ du -sh .git/ 
11M .git/ 


Git 提 供 了 git fsck 命 令 ， 可 以 查看 到 版 本 库 中 包含 的 没有 被 任何 引 
用 关联 的 松散 对 象 。 


$ git fsck 
dangling blob 2ebcd92dodda2bad50c775dc662c6cb700477aff 











标识 为 dangling 的 对 象 就 是 没有 被 任何 引用 直接 或 间接 关联 到 的 对 
象 。 这 个 对 象 就 是 前 面 通过 暂 存 区 操作 引入 的 大 文件 的 内 容 。 如 何 将 这 
个 文件 从 版 本 库 中 彻底 删除 呢 ? Git 提 供 了 一 个 清理 的 命令 : 


$ git prune 


用 git prune 清 理 之 后 ， 会 发 现 : 


用 git fsck 查 看 ， 没 有 未 被 关联 到 的 松散 对 象 。 





$ git fsck 





. 版 本 库 的 空间 占用 也 小 了 10MB ， 证 明 大 的 临时 对 象 文 件 已 经 从 
版 本 库 中 删除 了 。 





$ du -sh .git/ 
236K .git/ 





14.3 ” 重 置 操作 引入 的 对 象 


上 一 节 用 git prune 命 令 清除 暂 存 区 操作 时 引入 的 临时 对 象 ， 但 是 如 
条 是 用 重 置 命令 抛弃 的 提交 和 文件 就 不 会 轻易 地 被 清除 。 下 面 用 同样 的 
大 文件 提交 到 版 本 库 中 试验 一 下 。 








$ cd /path/to/my/workspace/i-am-admin 
$ cp /tmp/bigfile bigfile 
$ cp /tmp/bigfile bigfile.dup 





将 这 两 个 大 文件 提交 到 版 本 库 中 。 


添加 到 暂 存 区 0 





$ git add bigfile bigfile.dup 





` 提交 到 版 本 库 。 





$ git commit -m "add bigfiles." 

[master 51519c7] add bigfiles. 

2 files changed, 0 insertions(+), 0 deletions(-) 
create mode 100644 bigfile 

create mode 100644 bigfile.dup 





` 查看 版 本 库 的 空间 占用 。 





$ du -sh .git/ 
11M .git/ 





做 一 个 重 置 操 作 ， 抛 茎 刚刚 针对 两 个 大 文件 做 的 提交 。 





$ git reset --hard HEAD^ 








重 置 之 后 ， 看 看 版 本 库 的 变化 。 





. 版 本 库 的 空间 占用 没有 变化 ， 还 是 那么 “庞大 。 





$ du -sh .git/ 
11M .git/ 





` 查看 对 象 库 ， 看 到 三 个 松散 对 象 。 





$ find .git/objects/ -type f 

.git/objects/info/packs 
.git/objects/2e/bcd92dodda2bad50c775dc662c6cb700477aff 
.git/objects/d9/38dee8fde4e5053b12406c66a19183a24238e1 
.git/objects/51/519c7d8d60e0f958e135e8b989a78e84122591 
.git/objects/pack/pack-969329578b95057b7ea1208379a22c250c3b992a.idx 
.git/objects/pack/pack-969329578b95057b7ea1208379a22c250c3b992a.pack 





` 这 三 个 松散 对 象 分 别 对 应 于 撤销 的 提交 、 目 录 树 ， 以 及 大 文件 对 
应 的 blob 对 象 。 





$ git cat-file -t 51519c7 
commit 

$ git cat-file -t d938dee 
tree 

$ git cat-file -t 2ebcd92 
blob 





同上 一 节 一 样 ， 执 行 git prune 命 令 ， 期 竺 版 本 库 空 间 占 用 会 变 小 。 


. 版 本 库 空 间 占 用 没有 变化 ! 





$ git prune 
$ du -sh .git/ 
11M .git/ 





` 执行 git fsck 也 看 不 到 未 被 关联 到 的 对 象 。 





$ git fsck 





` 除非 像 下 面 这 样 执 行 。 





$ git fsck --no-reflogs 
dangling commit 51519c7d8d60e0f958e135e8b989a78e84122591 








还 记得 前 面 章节 中 介绍 的 reflog 吗 ? reflog 是 防止 误 操作 的 最 后 一 首 
闻 门 。 





$ git reflog 
6652a0d HEAD@{0}: HEAD^: updating HEAD 
51519c7 HEAD@{1}: commit: add bigfiles. 





可 以 看 到 撤销 的 操作 仍然 记录 在 reflog 中 ， 正 因为 如 此 ，Git 认 为 撤 
销 的 提交 和 大 文件 都 可 以 被 退 踪 到 ， 还 在 使 用 着 ， 所 以 无 法 用 git prune 


命令 删除 。 


如 果 确 认真 的 要 丢弃 不 想 要 的 对 象 ， 需 要 对 版 本 库 的 reflog 做 过 期 
操作 ， 相 当 于 将 .git/logs/ 下 的 文件 清空 。 


` 使 用 下 面 的 teflog 过 期 命令 做 不 到 让 刚刚 撤销 的 提交 过 期 ， 因 为 
reflog 的 过 期 操作 默认 只 会 让 90 天 前 的 数据 过 期 。 





$ git reflog expire --all 

$ git reflog 

6652a0d HEAD@{0}: HEAD^: updating HEAD 
51519c7 HEAD@{1}: commit: add bigfiles. 





` 需要 为 git teflog 命 令 提 供 --expite= 参 数 ， 强 制 让 之 前 的 记录 全 部 过 


期 。 





$ git reflog expire --expire=now --all 
$ git reflog 





使 用 now 作 为 时 间 参 数 ， 让 reflog 的 全 部 记录 都 过 期 。 没 有 了 
reflog， 即 从 reflog 中 看 不 到 回 深 的 添加 大 文件 的 提交 后 ， 该 提交 对 应 的 
commit 对 象 、tree 对 象 和 blob 对 象 束 会 成 为 未 被 关联 的 dangling 对 象 ， 可 
以 用 git prune 命 令 清理 。 下 面 可 以 看 到 清理 后 ， 版 本 库 变 小 了 。 











$ git prune 
$ du -sh .git/ 
244K .git/ 





A 记 >v 


14.4 Git 避 条 : glit-gC 


前 面 两 而 介绍 的 是 比较 极端 的 情况 ， 实 际 操作 中 会 很 少 用 到 git 
prune 命 令 来 清理 版 本 库 ， 而 是 会 使 用 一 个 更 为 常用 的 命令 git gc。 命 令 
git gc 束 好 比 Git 版 本 库 的 管家 ， 会 对 版 本 库 进行 一 系列 的 优化 动作 : 


(1) 对 分 散在 .givrefs 下 的 文件 进行 打包 ， 打 包 到 文件 .git/packed- 
refs 中 。 


如 果 没 有 将 配置 gc.packrefs 关 闭 ， 就 会 执行 命令 : git pack-refs--all-- 
prune 实 现 对 引用 的 打包 。 





(2) 丢弃 90 天 前 的 reflog 记 录 。 


会 运行 reflog 过 期 命令 : git reflog expire--all。 因 为 采用 了 默认 参数 


调用 ， 因 此 只 会 清空 reflog 中 90 天 前 的 记录 。 
(3) 对 松散 对 象 进行 打包 。 


运行 git repack 命 令 ， 几 是 有 引用 关联 的 对 象 部 被 打 在 包 里 ， 未 被 关 
联 的 对 象 仍旧 以 松散 对 象 的 形式 保存 。 


(4) 清除 未 被 关联 的 对 象 。 默 认 只 清除 2 周 以 前 的 未 被 关联 的 对 


可 以 同 git gc 提供 --prune=<date> 参 数 ， 其 中 的 时 间 参 数 传递 给 git 
prune--expire<date>， 实 现 对 指定 日 期 之 前 的 未 被 关联 的 松散 对 象 进行 
清理 。 





(5) 其 他 清理 。 





如 运行 git rerere gc 对 合并 冲突 的 历史 记录 进行 过 期 操作 。 


从 上 面 的 描述 中 可 见 命令 git gc 完成 了 相当 多 的 优化 和 清理 工作 ， 
并 且 最 大 限度 地 照顾 了 安全 性 的 需要 。 例 如 像 暂 存 区 操作 引入 的 没有 关 
联 的 临时 对 象 会 最 少 保留 2 个 星期 ， 而 因为 重 置 而 丢弃 的 提交 和 文件 则 


会 保留 最 少 3 个 月 。 








下 面 就 把 前 面 的 例子 用 git gc 再 执行 一 过 ， 不 过 这 一 次 添加 的 两 个 
大 文件 要 稍 有 不 同 ， 以 便 看 到 git gc 打包 所 实现 的 对 象 增 量 存储 的 效 
果 。 


复制 两 个 大 文件 到 工作 区 。 


$ cp /tmp/bigfile bigfile 
$ cp /tmp/bigfile bigfile.dup 


在 文件 bigfile.dup 后 面 追 加 些 内 容 ， 以 造成 bigfile 和 bigfile.dup 内 容 
不 辐 O 


$ echo "hello world" >> bigfile.dup 


将 这 两 个 稍 有 不 同 的 文件 提交 到 版 本 库 。 





$ git add bigfile bigfile.dup 

$ git commit -m "add bigfiles." 

[master c62fa4d] add bigfiles. 

2 files changed, © insertions(+), 0 deletions(-) 
create mode 100644 bigfile 

create mode 100644 bigfile.dup 











可 以 看 到 版 本 库 中 提交 进来 的 两 个 不 同 的 大 文件 是 不 同 的 对 象 。 





$ git ls-tree HEAD | grep bigfile 
100644 blob 2ebcd92d60dda2bad50c775dc662c6cb700477aff bigfile 
100644 blob 9e35f946a30c1i1ic47baidf351ca22866bc351e7b bigfile.dup 





做 版 本 库 重 置 ， 抛 弃 最 新 的 提交 ， 即 抛弃 添加 两 个 大 文件 的 提交 。 





$ git reset --hard HEAD^ 
HEAD is now at 6652a0d Add Images for git treeview. 








此 时 的 版 本 库 有 多 大 呢 ， 还 是 像 之 前 添加 两 个 相同 的 大 文件 时 占用 
11MB 的 空间 么 ? 





$ du -sh .git/ 
22M .git/ 














版 本 库 空 间 占 用 居然 扩大 了 一 倍 ! 这 显然 是 因为 两 个 大 文件 分 开 存 
储 造成 的 。 可 以 用 下 面 的 命令 在 对 象 库 中 得 看 对 象 的 大 小 。 











$ find .git/objects -type f -printf "%-20p\t%s\n" 
.git/objects/0c/844d2a072fd69e71638558216b69ebc57ddb64 233 
.git/objects/2e/bcd92dodda2bad50c775dc662c6cb700477aff 11184682 
.git/objects/9e/35f946a30c11c47baidf351ca22866bc351e7b 11184694 


.git/objects/c6/2fa4d6cb4c082fadfa45920b5149a23fd7272e 162 
.git/objects/info/packs 54 
.git/objects/pack/pack-969329578b95057b7ea1208379a22c250c3b992a.idx 2892 
.git/objects/pack/pack-969329578b95057b7ea1208379a22c250c3b992a.pack 80015 














输出 的 每 一 行 用 空白 分 隔 ， 前 面 是 文件 名 ， 后 面 是 以 字 节 为 单位 的 
文件 大 小 。 从 上 面 的 输出 中 可 以 看 出 来 ， 打 包 文 件 很 小 ， 但 是 有 两 个 大 
的 文件 各 自 占 用 了 11MB 左 右 的 空间 。 


执行 git gc 并 不 会 删除 任何 对 象 ， 因 为 这 些 对 象 都 还 没有 过 期 。 但 
是 会 发 现 版 本 库 的 占用 空间 变 小 了 。 


` 执行 git gc 对 版 本 库 进行 整理 。 





$ git gc 

Counting objects: 69, done. 

Delta compression using up to 2 threads. 
Compressing objects: 100% (49/49), done. 
Writing objects: 100% (69/69), done. 
Total 69 (delta 11), reused 63 (delta 8) 





` 版 本 库 空间 占用 小 了 一 半 ! 





$ du -sh .git/ 
11M .git/ 





` 原来 是 因为 对 象 库 重 新 打包 ， 两 个 大 文件 采用 了 增 量 存储 使 得 版 





$ find .git/objects -type f -printf "%-20p\t%s\n" | sort 

.git/objects/info/packs 54 
.git/objects/pack/pack-7cae010c1b064406cd6c1i6d5a6ab2f446de4076c .idx 3004 
.git/objects/pack/pack-7cae010c1b064406cd6c1i6d5a6ab2f446de4076c ,pack 11263033 





如 末 想 将 抛弃 的 历史 数据 彻 奈 丢弃 ， 进 行 如 下 操作 。 


(1) 不 再 保留 90 天 的 reflog， 而 是 将 所 有 reflog 全 部 即时 过 期 。 





$ git reflog expire --expire=now --all 





(2) 通过 git fsck 可 以 看 到 有 提交 成 为 了 未 被 关联 的 提交 。 





$ git fsck 
dangling commit c62fa4d6cb4c082fadfa45920b5149a23fd7272e 





(3) 这 个 未 被 关联 的 提交 就 是 添加 大 文件 的 提交 。 





$ git show c62fa4d6cb4c082fadfa45920b5149a23fd7272e 
commit c62fa4d6cb4c082fadfa45920b5149a23fd7272e 
Author: Jiang Xin <jiangxin@ossxp.com> 
Date: Thu Dec 16 20:18:38 2010 +0800 
add bigfiles. 
diff --git a/bigfile b/bigfile 
new file mode 100644 
index 0000000. .2ebcd92 
Binary files /dev/null and b/bigfile differ 
diff --git a/bigfile.dup b/bigfile.dup 
new file mode 100644 
index 0000000. .9e35f94 
Binary files /dev/null and b/bigfile.dup differ 





(4) 不 带 参数 调用 git gc 虽然 不 会 清除 疝 示 过 期 “未 到 2 周 ) 的 大 
文件 ， 但 是 会 将 未 被 关联 的 对 象 从 打包 文件 中 移出 ， 成 为 松散 文件 。 





$ git gc 

Counting objects: 65, done. 

Delta compression using up to 2 threads. 
Compressing objects: 100% (45/45), done. 
Writing objects: 100% (65/65), done. 
Total 65 (delta 8), reused 63 (delta 8) 


一 于 


(5) 未 被 关联 的 对 象 重新 成 为 松散 文件 ， 所 以 .git 版 本 库 的 空间 占 
用 多 有 反弹 





$ du -sh .git/ 

22M .git/ 

$ find .git/objects -type f -printf "%-20p\t%s\n" | sort 
.git/objects/0c/844d2a072fd69e71638558216b69ebc57ddb64 233 
.git/objects/2e/bcd92dodda2bad50c775dc662c6cb700477aff 11184682 
.git/objects/9e/35f946a30c11c47baidf351ca22866bc351e7b 11184694 
.git/objects/c6/2fa4d6cb4c082fadfa45920b5149a23fd7272e 162 
.git/objects/info/packs 54 
.git/objects/pack/pack-969329578b95057b7ea1208379a22c250c3b992a.idx 2892 
.git/objects/pack/pack-969329578b95057b7ea1208379a22c250c3b992a.pack 80015 





(6) 实际 上 如 果 使 用 立即 过 期 参数 --prune=now 调 用 git gc， 束 不 用 
再 等 2 周 了 ， 直 接 就 可 以 完成 对 未 关联 的 对 象 的 清理 。 





$ git gc --prune=now 

Counting objects: 65, done. 

Delta compression using up to 2 threads. 
Compressing objects: 100% (45/45), done. 
Writing objects: 100% (65/65), done. 
Total 65 (delta 8), reused 65 (delta 8) 





(7) 清理 过 后 ， 版 本 库 的 空间 占用 降 了 下 来 。 





$ du -sh .git/ 
240K .git/ 





14.5 ”Git 管 家 的 自动 执行 


对 于 老 版 本 库 的 Git， 会 看 到 帮助 手册 中 建议 用 户 对 版 本 库 进行 周 
期 性 的 整理 ， 以 便 获 得 更 好 的 性 能 ， 尤 其 是 对 于 规模 比较 大 的 项 目 ， 但 
征 对 于 整理 的 周期 都 语 融 不 详 。 








实际 上 对 于 1.6.6 及 以 后 版 本 的 Git 已 经 基本 上 不 需要 手动 执行 git gc 
命令 了 ， 因 为 部 分 Git 命 令 会 自动 调用 git gc--auto 命 令 ， 在 版 本 库 确实 需 
要 整理 的 情况 下 自动 开始 整理 操作 。 


目前 有 如 下 的 Git 命 令 会 自动 执行 git gc--auto 命 令 ， 实 现 对 版 本 库 的 


. 执行 命令 git merge 进 行 合并 操作 后 ， 对 版 本 库 进 行 按 需 整理 。 


" 执行 命令 git receive-pack， 即 版 本 库 接 收 其 他 版 本 库 PUSH 来 的 提 
交 后 ， 对 版 本 库 进 行 按 需 整理 操作 。 


当 版 本 库 接收 到 其 他 版 本 库 的 PUSH 请 求 时 ， 会 调用 git receive-pack 
命令 以 接收 请 求 。 在 接收 到 推送 的 提交 后 ， 对 版 本 库 进行 按 需 整 理 。 





` 执行 命令 git rebase-i 进 行 交互 式 变 基 操 作 后 ， 会 对 版 本 库 进 行 按 


. 执行 命令 git am 对 mbox 邮 箱 中 通过 邮件 提交 的 补丁 在 版 本 库 中 进 
行 应 用 的 操作 后 ， 会 对 版 本 库 做 按 需 整理 操作 。 


综 上 所 述 ， 对 于 提供 共有 至 式 “ 写 操作 ”的 Git 版 本 库 ， 可 以 免 维护 。 所 
请 的 共 至 式 写 操作 ， 就 是 版 本 库 作为 一 个 裸 版 本 库 放 在 服务 占 上 ， 团 队 
成 员 可 以 通过 PUSH (推送 ) 操作 将 提交 推送 到 共享 的 裸 版 本 中 。 每 一 
次 推送 操作 都 会 触发 git gc--auto 命 令 ， 对 版 本 库 进行 按 需 整理 。 











还 有 ， 对 于 非 独立 工作 的 本 地 工作 区 ， 也 可 以 免 维 护 。 因 为 和 他 人 
协同 工作 的 本 地 工作 区 会 经 名 执行 git pull 操 作 从 他 人 版 本 库 或 从 共 圣 的 
版 本 库 拉 回 新 提交 ， 执 行 git pull 操 作 会 触 友 git merge 操 作 ， 因 此 也 会 对 
本 地 版 本 库 进 行 按 需 整 理 。 


在 对 版 本 库 进行 授 需 整理 时 ， 整 理 的 频率 是 一 个 问题 。 如 果 整 理 得 
太 勤 则 没有 必要 ， 还 会 增加 系统 负担 ; 但 如 果 下 于 整理 则 会 导致 积累 太 
多 的 松散 文件 ， 当 真正 开始 版 本 库 整 理 的 时 候 会 占用 过 多 的 系统 资源 ， 
影响 用 户 体验 。 因 此 实际 操作 中 只 有 在 特定 的 条 件 下 才 会 触发 真正 的 版 
本 库 整 理 。 





主要 的 触 上 友 条 件 是 : 松散 对 象 只 有 超过 一 定 的 数量 时 才 会 执行 。 在 
统计 松散 对 象 数 量 时 ， 为 了 降低 在 .git/objects/ 目 录 下 搜索 松散 对 象 对 系 
统 造成 的 负担 ， 实 际 采取 了 取样 搜索 ， 即 只 会 对 对 象 库 下 的 一 个 子 目 
录 .git/objects/17 进 行文 件 搜索 。 在 默认 的 配置 下 ， 只 有 该 目录 中 对 象 数 





目 超 过 27 个 才 会 触发 版 本 库 的 整理 。 至 于 为 什么 只 在 对 象 库 中 选择 一 个 
子 目录 进行 松散 对 象 的 搜索 ， 这 是 因为 SHA1 哈 希 值 是 完全 随机 的 ， 文 
件 在 由 前 两 位 哈 希 值 组 成 的 目录 中 差不多 是 平均 分 布 的 。 至 于 为 什么 选 
择 17， 不 知道 对 于 作者 Junio C Hamano 有 什么 特殊 意义 ， 也 许 是 向 Linus 
Torvalds 被 评选 为 20 世 纪 最 有 影响 力 的 100 人 中 排名 第 17 位 而 致敬 中 。 





一 /一 


可 以 通过 设置 配置 变量 gc.auto 的 值 ， 调 整 Git 管 家 自动 运行 时 触发 版 
本 库 整 理 操作 的 频率 。 默 认 gc.auto 的 值 为 6700， 是 触发 版 本 库 整 理 的 全 
部 松散 对 象 数 的 阅 值 ， 对 于 单个 取样 目录 .git/objects/17 来 说 ， 超 过 
《6700+255) /256 个 文件 时 即 开始 版 本 库 整 理 。 但 是 注意 不 要 将 gc.auto 
设置 为 0， 否 则 git gc--auto 命 令 永远 不 会 触发 版 本 库 的 整理 。 








[1] http:/ /en.wikipedia.org/wiki/ Linus_Torvalds 


第 3 篇 Git 和 声 


上 一 篇 的 各 章 是 从 个 人 使 用 的 角度 研究 和 学 习 Git， 通 过 连续 的 实 
践 不 但 学 习 了 Git 的 基本 用 法 ， 还 深入 地 了 解 了 Git 的 奥秘 ， 这 些 都 将 成 
为 学 习 本 篇 内 容 的 基础 。 本 篇 不 再 是 一 个 人 的 独 委 ， 而 是 多 人 的 和 声 ， 
我 们 将 从 团队 使 用 的 角度 对 Git 进 行 研究 。 要 知道 Git 作 为 版 本 控制 系 
统 ， 其 主要 工作 就 是 团队 协作 。 


团队 协作 和 个 人 之 间 有 何不 同 ? 关键 残 在 于 团队 成 员 之 间 存 在 着 数 
据 交 换 : 


. 数据 交换 需要 协议 ， 这 就 是 第 15 章 要 介绍 的 内 容 。 


- 数据 交换 可 能 会 因为 冲突 造成 中 断 ， 第 16 章 将 专题 介绍 如 何 解决 


. 里 程 碑 为 数据 建立 标识 ， 是 数据 交换 的 参照 点 ， 这 将 在 第 17 章 中 


: 分支 会 为 数据 交换 开辟 不 同 的 通道 ， 从 而 减少 冲突 和 混乱 的 发 


生 ， 第 18 章 会 系统 地 介绍 不 同 的 分 支 应 用 模型 。 


:与 远程 版 本 库 进 行 数据 交换 ， 是 Git 协 同 的 重要 内 容 ， 这 将 在 第 


19 章 中 介绍 。 


` 本 篇 的 最 后 (第 20 章 ) 会 介绍 在 不 能 直接 与 其 他 版 本 库 交 互 的 情 
况 下 ， 如 何以 补丁 文件 的 方式 进行 数据 交换 。 


第 15 章 ”Git 协议 与 工作 协同 


要 想 团 队 协 作 使 用 Git， 就 需要 用 到 Git 协 议 。 


15.1 Git 支持 的 协议 


首先 来 看 看 数据 交换 需要 使 用 的 协议 。 


Git 提 供 了 丰富 的 协议 支持 ， 包 括 : SSH、GIT、HTTP、HTTPS、 
FIP、FTPS、RSYNC 及 前 面 已 经 看 到 的 本 地 协议 等 。 各 种 不 同 协议 的 
URL 写 法 如 表 15-1 所 示 。 


协议 名 称 


表 15-1 


语法 格式 


Git 支 持 的 协议 


说 明 





SSH 协议 (1) 


ssh://[user@l]example.com[:port]/path/to/repo.git/ 


可 在 URL 中 设置 用 户 名 和 端口 。 默 认 端 口 22 





SSH 协议 (2) 


[user@]example.com:path/to/repo.git/ 


SCP 格式 表示 法 ， 更 简洁 。 但 是 非 默认 端 
口 需要 通过 其 他 方式 (如 主机 别名 方式 ) 
设 定 














GIT 协议 git://example.com[:port]/path/to/repo.git/ 最 常用 的 只 读 协 议 
HTTP[S] 协议 http[s]://example.com[:port]/path/to/repo.git/ 兼 有 智能 协议 和 哑 协 议 
FTP[S] 协议 ftp[s]://example.com[:port]/path/to/repo.git/ 呈 协 议 

RSYNC 协议 rsync://example.com/path/to/repo.git/ 哑 协 议 


本 地 协议 (1) 


file:///path/to/repo.git 





本 地 协议 (2) 





/path/to/repo.git 





和 file:// 格式 的 本 地 协议 类 似 ， 但 有 细微 关 
别 。 例 如 克隆 时 不 支持 浅 克隆 ， 且 采用 直接 
的 硬 连接 实现 克隆 


上 面 介 绍 的 各 种 协议 可 分 为 两 类 : 智能 协议 和 哑 协 议 。 


在 会 话 时 使 用 智能 协议 ， 会 在 会 话 的 两 个 版 本 库 的 各 自 一 端 打开 相 


应 的 程序 进行 数据 交换 。 使 用 智能 协议 最 直观 的 印象 就 是 在 数据 传输 过 
程 中 会 有 清晰 的 进度 显示 ， 而 且 因 为 是 按 需 传输 所 以 传输 量 更 小 ， 速 度 
更 快 。 图 15-1 显 示 的 就 是 在 执行 PULL 和 PUSH 两 个 最 常用 的 操作 时 ， 两 
个 版 本 库 各 自 启 动 辅 助 程序 的 情况 。 








git push 
git pull 


git-fetch-pack git-upload-pack 


本 地 版 本 库 远程 版 本 库 


图 15-1 Git 智能 协议 通信 示意 图 





上 述 协议 中 SSH、GIT 及 本 地 协议 〈fie:/) 属于 智能 协议 。HTTP 协 
议 需 要 特殊 的 配置 〈 用 git-http-backend 配 置 CGI) ， 并 且 客 户 端 需要 使 
用 Git 1.6.6 或 更 高 的 版 本 才能 够 使 用 智能 协议 。 


2. 哑 协议 

和 智能 协议 相对 的 是 哑 协 议 。 在 使 用 哑 协 议 访问 远程 版 本 库 的 时 
候 ， 远 程 版 本 库 不 会 运行 辅助 程序 ， 而 是 完全 依靠 客户 端 去 主动 “发 
现 ”。 客 户 端 需 要 访问 文件 .giUVinfomrefs 获 取 当 前 版 本 库 的 引用 列表 ， 并 
根据 引用 对 应 的 提交 ID 直接 访问 对 象 库 目 录 下 的 文件 。 如 果 对 象 文件 被 














打包 而 不 是 以 松散 对 象形 式 存在 ， 则 Git 客 户 端 还 要 去 访问 文 

件 .git/objects/info/packs 以 获得 打包 文件 列表 ， 并 据 此 读 取 完整 的 打包 文 
件 ， 从 打包 文件 中 获取 对 象 。 由 此 可 见 哑 协议 的 效率 非常 之 低 ， 甚 至 会 
因为 要 获取 一 个 对 象 而 去 访问 整个 pack 包 。 





使 用 哑 协 议 最 直观 的 感受 是 : 传输 速度 非常 慢 ， 而 且 传输 进度 不 可 
见 ， 不 知道 什么 时 候 才 能 够 完成 数据 传输 。 上 述 协议 中 ，FTP 和 RSYNC 
都 是 哑 协 议 ， 没 有 通过 git-http-backend 或 类 似 CGI 程 序 配 置 的 HITP 服 务 
器 提供 的 也 是 哑 协 议 。 因 为 哑 协 议 需 要 索引 文件 .giUinfo/refs 
和 .gityobjects/info/packs 以 获取 引用 和 包 列 表 ， 因 此 要 在 版 本 库 的 钩子 脚 
本 post-update 中 设置 运行 git update-server-info 以 确保 及 时 更 新 哑 协 议 需 
要 的 索引 文件 。 不 过 如 果 不 使 用 旺 协 议 ， 运 行 git update-server-info 就 没 
有 什么 必要 了 。 





以 Git 项 目 本 身 为 例 ， 看 看 如 何 使 用 不 同 的 协议 地 址 进行 版 本 库 殉 


“GIT 协议 (智能 协议 ) : 





$ git clone git://git.kernel.org/pub/scm/git/git.git 





" HITP (S) 哑 协 议 : 





$ git clone http://www.kernel.org/pub/scm/git/git.git 





- HITP (S) 智能 协议 门 : 





$ git clone https://github.com/git/git.git 





[1 使 用 Git 1.6.6 或 更 高 版 本 访问 。 


15.2 多 用 户 协 同 的 本 地 模拟 


在 本 篇 的 学 习 过 程 中 ， 需 要 一 个 能 够 提供 多 人 访问 的 版 本 库 ， 显 然 
要 找到 一 个 公共 服务 器 ， 并 且 能 让 所 有 人 都 尽情 发 挥 不 太 容易 ， 但 幸好 
可 以 使 用 本 地 协议 来 模拟 。 在 后 面 的 内 容 中 ， 会 经 常 使 用 本 地 协议 地 址 
file:///path/to/repos/<project>.git 来 代表 对 某 一 公共 版 本 库 的 访问 ， 您 可 以 
把 file:/ 格 式 的 URL 《〈 比 直接 使 用 路 径 方 式 更 逼真 ) 想象 为 git:/ 或 http:/ 
格式 ， 并 且 想 象 它 是 在 一 台 远 程 的 服务 器 上 ， 而 非 本 机 。 


同样 地 ， 为 了 模拟 多 人 的 操作 ， 也 不 再 使 用 /path/to/my/workspace 作 
为 工作 区 ， 而 是 分 别 使 用 /path/to/user1/workspace 
和 /path/tomuser2/workspace 等 路 径 来 代表 不 同 用 户 的 工作 环境 。 同 样 想 
象 /path/to/user1/ 和 /path/to/user2/ 是 在 不 同 的 主机 上 ， 并 由 不 同 的 用 户 进 
行 操作 。 








下 面 就 来 演示 一 个 共 侍 版 本 库 的 搭建 过 程 ， 以 及 两 个 用 户 user1 和 
user2 在 各 自 的 工作 区 中 是 如 何 工作 并 进行 数据 交换 的 ， 具 体 过 程 如 下 。 





(1) 于 /path/to/repos/shared.git 中 创建 一 个 共享 的 版 本 库 。 


别 瑟 了 在 第 2 篇 的 “第 13 间 Git 元 隆 ” 一 半 中 介绍 的 ， 以 裸 版 本 库 方式 
创建 。 


$ git init --bare /path/to/repos/shared.git 
Initialized empty Git repository in /path/to/repos/shared.git/ 





(2) 用 户 user1 克 隆 版 本 库 。 


从 下 面 的 命令 输出 可 以 看 出 ， 克 隆 一 个 刚刚 初始 化 完成 的 裸 版 本 库 
会 显示 一 个 警告 ， 警 告 正在 克隆 的 版 本 库 是 一 个 空 版 本 库 。 





$ cd /path/to/user1i/workspace 

$ git clone file:///path/to/repos/shared.git project 
Cloning into project... 

warning: You appear to have cloned an empty repository. 





(3) 设置 user.name 和 user.email 配 置 变 量 。 


要 在 版 本 库 级 别 设置 user.name 和 user.email 配 置 变量 〈( 即 运行 git 
config 命 令 时 不 使 用 --global 或 --system 参 数 ) ， 以 便 和 全 局 设置 区 分 开 ， 
因为 我 们 的 模拟 环境 中 所 有 用 户 都 共享 同一 全 局 设置 和 系统 设置 。 








$ cd project 
$ git config user.name user1 
$ git config user.email useri@sun.ossxp.com 





(4) 用 户 user1 创 建 初始 数据 并 提交 





$ echo Hello. > README 

$ git add README 

$ git commit -m "initial commit." 

[master (root-commit) 5174bf3] initial commit. 

1 files changed, 1 insertions(+), 0 deletions(-) 
create mode 100644 README 





(5) 用 户 user1 将 本 地 版 本 库 的 提交 推送 到 上 游 。 


在 下 面 的 推送 指令 中 使 用 了 origin 别 名 ， 其 实际 指向 就 是 
file:///path/to/repos/shared.git。 可 以 从 .git/config 配 置 文件 中 看 到 是 如 何 实 
现 对 origin 远 程 版 本 库 注册 的 。 关 于 远程 版 本 库 的 内 容 将 在 第 19 章 介 


绍 。 








$ git push origin master 
Counting objects: 3, done. 
Writing objects: 100% (3/3), 210 bytes, done. 
Total 3 (delta 0), reused 0 (delta 0) 
Unpacking objects: 100% (3/3), done. 
To file:///path/to/repos/shared.git 

* [new branch] master -> master 





(6) 用 户 user2 克 隆 版 本 库 。 





用 户 user2 殉 隆 时 没有 显示 和 警告， 因为 此 时 共享 版 本 库 已 不 再 是 空 版 
本 库 了 。 








$ cd /path/to/user2/workspace 

$ git clone file:///path/to/repos/shared.git project 
Cloning into project... 

remote: Counting objects: 3, done. 

remote: Total 3 (delta 0), reused 0 (delta 0) 
Receiving objects: 100% (3/3), done. 





(7) 同样 在 user2 的 本 地 版 本 库 中 ， 设 置 user.name 和 user.email 配 置 
变量 ， 以 区 别 全 局 配置 设置 。 











$ cd /path/to/user2/workspace/project 
$ git config user.name user2 
$ git config user.email user2@moon.ossxp.com 





(8) 用 户 user2 的 本 地 版 本 库 现在 拥有 和 user1 用 户 同 样 的 提交 。 


PPT 一 | 
$ git 1og 
commit 5174bf33ab31a3999a6242fdcb1ec237e8f3f91a 
Author: user1 <user1iQ@sun.ossxp.com> 


Date: Sun Dec 19 15:52:29 2010 +0800 
initial commit. 


二 一 


15.3 “强制 非 快 进 式 推 运 


现在 用 户 user1 和 user2 的 工作 区 是 相同 的 。 思 考 一 个 问题 : 如 果 两 
人 各 自在 本 地 版 本 库 中 进行 独立 的 提交 ， 人 然后 再 分 别 问 共享 版 本 库 推 
送 ， 会 互相 窗 新 么 ? 为 了 回答 这 个 问题 ， 进 行 下 面 的 实践 。 





首先 ， 用 户 user1 先 在 本 地 版 本 库 中 进行 提交 ， 然 后 将 本 地 的 提交 推 
送 到 “远程 ” 共 译 版 本 库 中 ， 操 作 步 又 如 下 。 


(1) 用 户 user1 创 建 team/user1.txt 文 件 。 


假设 这 个 项 目 约 定 : 每 个 开发 者 在 team 目 录 下 写 一 个 自述 文件 。 于 
是 用 户 user1 创 建文 件 team/userl1.txt。 





$ cd /path/to/user1i/workspace/project/ 

$ mkdir team 

$ echo "I'm user1." > team/user1.txt 

$ git add team 

$ git commit -m "User1's profile." 

[master b4f3ae0] User1's profile. 

1 files changed, 1 insertions(+), 0 deletions(-) 
create mode 100644 team/user1.txt 





(2) 用 户 user1 将 本 地 提交 推送 到 服务 器 上 。 





$ git push 

Counting objects: 5, done. 

Delta compression using up to 2 threads. 
Compressing objects: 100% (2/2), done. 
Writing objects: 100% (4/4), 327 bytes, done. 
Total 4 (delta 0), reused 0 (delta 0) 
Unpacking objects: 100% (4/4), done. 


To file:///path/to/repos/shared.git 
5174bf3..b4f3ae0 master -> master 





(3) 查看 当前 userl 版 本 库 中 的 日 志 。 





$ git 1og --oneline --graph 
* b4f3ae0 useri1's profile. 
* 5174bf3 initial commit. 








通过 上 面 的 操作 步骤 ， 可 以 看 到 用 户 userl 成 功 地 更 新 了 “远程 ”共享 
版 本 库 。 如 果 用 户 user2 不 知道 用 户 userl 所 做 的 上 述 操作 ， 仍 在 基于 “ 远 
时 ?版 本 库 旧 数据 同步 而 来 的 本 地 版 本 库 中 进行 改动 ， 然 后 用 户 user2 
向 “远程 > 共享 版 本 库 推 送 ， 会 有 什么 结果 呢 ? 用 下 面 的 操作 验证 一 下 。 





(1) 用 户 user2 创 建 team/user2.txt 文 件 。 





$ cd /path/to/user2/workspace/project/ 

$ mkdir team 

$ echo "I'm user1?" > team/user2.txt 

$ git add team 

$ git commit -m "user2's profile." 

[master 8409e4c] user2's profile. 

1 files changed, 1 insertions(+), 0 deletions(-) 
create mode 100644 team/user2.txt 





(2) 用 户 user2 将 本 地 提交 推送 到 服务 器 时 出 错 。 





$ git push 
To file:///path/to/repos/shared.git 
! [rejected] master -> master (non-fast-forward) 


error: failed to push some refs to 'file:///path/to/repos/shared.git'" 

To prevent you from losing history, non-fast-forward updates were rejected 
Merge the remote changes (e.g. 'git pull') before pushing again. See the 
'Note about fast-forwards' section of 'git push --help' for details. 


i 


(3) 将 用 户 user2 推 送 失 败 的 错误 日 志 翻 译 如 下 : 





到 版 本 库 file:///path/to/repos/shared.git 

! [被 拒绝 ] master -> master ( 非 快 进 ) 
错误 : 部 分 引用 向 'file:///path/to/repos/shared.git' 推送 失败 
为 防止 您 丢失 历史 数据 ， 非 快 进 式 更 新 被 拒绝 。 
在 推送 前 请 先 合 并 远程 改动 ， 例 如 执行 'git pull'。 







































































用 户 user2 推 送 失 败 了 。 但 这 不 是 坏事 ， 反 倒是 一 件 好 事情 ， 因 为 这 
避免 了 用 户 提交 的 相互 覆盖 。Git 通 过 检查 推送 操作 是 不 是 “ 快 进 式 ”的 操 
作 ， 从 而 保证 用 户 的 提交 不 会 相互 履 盖 。 一 般 情况 下 ， 推 送 只 允许 “ 快 
进 式 ” 推 送 。 所 谓 快 进 式 推 送 ， 束 是 要 推送 的 本 地 版 本 库 的 提交 是 建 这 
在 远程 版 本 库 相 应 分 支 的 现 有 提交 基础 上 的 ， 即 远程 版 本 库 相 应 分 支 的 
最 新 提交 是 本 地 版 本 库 最 新 提交 的 祖先 提交 。 但 现在 用 户 user2 执 行 的 推 
送 并 非 如 此 ， 是 一 个 非 快 进 式 的 推送 。 














. 此 时 用 户 user2 本 地 版 本 库 的 最 新 提交 及 其 历史 提交 可 以 用 git rev- 


list 命 令 显示 ， 如 下 所 示 : 





$ git rev-list HEAD 
8409e4c72388a18ea89eecb86d68384212c5233f 
5174bf33ab31a3999a6242fdcb1ec237e8f3f91a 





. 用 git ls-remote 命 令 显 示 远 程 版 本 库 的 引用 对 应 的 SHA1 哈 希 值 ， 
会 发 现 远程 版 本 库 所 包含 的 最 新 提交 的 SHA1 哈 希 值 是 b4f3ae0...， 不 是 本 


地 最 新 提交 的 祖先 提交 。 





$ git ls-remote origin 
b4f3ae0fcadce8c343f3cdc8a69c33cc98c98dfd HEAD 


b4f3aeofcadce8c343f3cdc8a69c33cc98c98dfd refs/heads/master 





实际 上 当 用 户 user2 执 行 推 送 的 时 候 ，Git 就 是 利用 类 似 方法 判断 出 
当前 的 推送 不 是 一 个 快 进 式 推 送 ， 于 是 产生 警告 并 终止 。 


那么 如 何 才能 成 功 推送 呢 ? 一 个 不 一 定 正确 的 解决 方案 是 : 强制 推 


在 推送 命令 的 后 面 使 用 -f 参 数 可 以 进行 强制 推送 ， 即 使 是 非 快 进 式 
的 推送 也 会 成 功 执行 。 用 户 user2 执 行 强制 推送 ， 会 强制 刷新 服务 器 中 的 
版 本 。 


$ git push -f 
Counting objects: 7, done. 
Delta compression using up to 2 threads. 
Compressing objects: 100% (3/3), done. 
Writing objects: 100% (7/7), 503 bytes, done. 
Total 7 (delta 0), reused 3 (delta 0) 
Unpacking objects: 100% (7/7), done. 
To file:///path/to/repos/shared.git 
+ b4f3ae0...8409e4c master -> master (forced update) 


注意 到 了 人 么 ， 在 强制 推送 的 最 后 一 行 输出 中 显示 了 “强制 更 新 
(forced update) ”字样 。 这 样 用 户 user1 向 版 本 库 推送 的 提交 由 于 用 户 
user2 的 强制 推送 被 覆盖 了 。 实 际 上 在 这 种 情况 下 user1 也 可 以 强制 推 
送 ， 从 而 用 自己 (user1) 的 提交 再 去 窗 新 用 户 user2 的 提交 。 这 样 的 工 
作 模 式 不 是 协同 ， 而 是 战争 ! 








在 上 面 用 户 user2 使 用 非 快 进 式 推送 强制 更 新 版 本 库 ， 实 际 上 是 危险 


的 。 滥 用 非 快 进 式 推 送 可 能 造成 提交 神主 大 战 〈 战 争 是 霸权 的 滥用 〉。 
正确 地 使 用 非 快 进 式 推送 ， 应 该 是 在 不 会 造成 提交 轿 兰 “战争 ”的 前 提 
下 ， 对 历史 提交 进行 修补 。 














下 面 的 操作 也 许 是 一 个 使 用 非 快 进 式 推送 的 更 好 的 例子 。 


(1) 用 户 user2 改 正之 前 错误 的 录入 。 





细心 的 读者 可 能 已 经 发 现 ， 用 户 user2 在 创建 个 人 描述 的 文件 中 把 自 
己 的 名 字 写 错 了 。 假 设 用 户 user2 在 刚刚 完成 回 服务 器 的 推送 操作 后 也 友 
现 了 这 个 错误 ， 于 是 user2 进 行 了 下 面 的 更 改 。 





$ echo "I'm user2." > team/user2 ,txt 
$ git diff 
diff --git a/team/user2.txt b/team/user2.txt 
index 27268e2..2dcb7b6 100644 
-- a/team/user2.txt 
+++ b/team/user2.txt 
@@ -1 +1 @@ 
-I'm User12? 
+I'm usSer2. 





(2) 然后 用 户 user2 将 修改 好 的 文件 提交 到 本 地 成 本 库 中 。 








采用 直接 提交 还 是 使 用 修补 式 提交 ， 这 是 一 个 问题 。 因 为 前 次 的 提 
交 已 经 被 推送 到 共享 版 本 库 中 ， 如 果 采 用 修补 提交 会 造成 前 一 次 提交 被 
新 提交 抹 掉 ， 从 而 在 下 次 推送 时 造成 非 快 进 式 推送 。 这 时 用 户 user2 就 要 
评估 “战争 ”的 风险 : “我 刚刚 推送 的 提交 ， 有 没有 可 能 被 其 他 人 获取 了 
(通过 git pull、git fetch 或 git alone 操作) ? ”如 有 果 确 认 不 会 有 他 人 获取 ， 





例如 现在 公司 里 只 有 user2 目 己 一 个 人 在 加 班 ， 那 么 可 以 放心 地 进行 修补 
操作 。 





$ git add -u 

$ git commit --amend -m "user2's profile." 

[master 6b1a7a0] user2's profile. 

1 files changed, 1 insertions(+), 0 deletions(-) 
create mode 100644 team/user2.txt 








(3) 采用 强制 推送 ， 更 新 远程 共 吝 版 本 库 中 的 提交 。 这 个 操作 越 
早 越 好 ， 在 他 人 还 没有 来 得 及 和 服务 器 同步 前 将 修补 提交 强制 更 新 到 服 
务 絮 上 。 








$ git push -f 
Counting objects: 5, done. 
Delta compression using up to 2 threads. 
Compressing objects: 100% (2/2), done. 
Writing objects: 100% (4/4), 331 bytes, done. 
Total 4 (delta 0), reused 0 (delta 0) 
Unpacking objects: 100% (4/4), done. 
To file:///path/to/repos/shared.git 
+ 8409e4c...6b1ia7ra0 master -> master (forced update) 


一 三 = 


15.4 合并 后 推送 


理性 的 工作 协同 要 避免 非 快 进 式 推 送 。 一 旦 同 服务 器 推送 后 ， 如 果 
发 现 错误 ， 不 要 使 用 会 更 改 历史 的 操作 ( 变 基 、 修 补 提交 ) ， 而 是 采用 
不 会 改变 历史 提交 的 反 转 提交 等 操作 。 





如 果 在 回 服 务 器 推送 过 程 中 ， 由 于 他 人 率先 推送 了 新 的 提交 导致 遭 
遇 到 非 快 进 式 推送 的 警告 ， 应 该 进行 如 下 操作 才 更 为 理性 : 执行 git pull 
获取 服务 露 端 最 新 的 提交 并 和 本 地 提交 进行 合并 ， 合 并 成 功 后 再 癌 服 务 


例如 用 户 user1 在 推送 时 遇 到 了 非 快 进 式 推送 错误 ， 可 以 通过 如 下 操 
作 将 本 地 版 本 库 的 修改 和 远程 版 本 库 的 最 新 提交 进行 合并 。 








(1) 用户 userl 发 现 推送 遇 到 了 非 快 进 式 推送 。 





$ cd /path/to/user1i/workspace/project/ 


$ git push 
To file:///path/to/repos/shared.git 
! [rejected] master -> master (non-fast-forward) 


error: failed to push some refs to 'file:///path/to/repos/shared.git'" 

To prevent you from losing history, non-fast-forward updates were rejected 
Merge the remote changes (e.g. 'git pull') before pushing again. See the 
'Note about fast-forwards' section of 'git push --help' for details. 





(2) 用 户 userl 运 行 git pull 命 令 。 








命令 git pull 实 际 包含 两 个 动作 :获取 远程 版 本 库 的 最 新 提交 ， 以 及 


将 获取 到 的 远程 版 本 库 提交 与 本 地 提交 进行 合并 。 





$ git pull 

remote: Counting objects: 5, done. 

remote: Compressing objects: 100% (2/2), done. 
remote: Total 4 (delta 0), reused 0 (delta 0) 
Unpacking objects: 100% (4/4), done. 

From file:///path/to/repos/shared 

+ b4f3ae0...6b1ia7a0 master -> origin/master (forced update) 
Merge made by recursive. 

team/user2.txt | 大" 党 

1 files changed, 1 insertions(+), 0 deletions(-) 
create mode 100644 team/user2.txt 








(3) 合并 之 后 ， 看 看 版 本 库 的 提交 关系 图 。 


合并 之 后 远程 服务 器 中 的 最 新 提交 6b1la7a0 成 为 当前 最 新 提交 〈 合 
并 提交 ) 的 父 提 区 之 一 。 如 果 再 推送 ， 则 不 再 是 非 快 进 式 的 了 。 





$ git 1og --graph --oneline 

C bccc620 Merge branch 'master' of file:///path/to/repos/shared 
人 | 

| * 6b1la7a0 user2's profile. 

* | b4f3ae0 User1's profile. 

I/ 

* 5174bf3 initial commit. 





(4) 执行 git push 命 令 ， 成 功 完成 到 远程 版 本 库 的 推送 。 





$ git push 

Counting objects: 10, done. 

Delta compression using up to 2 threads. 

Compressing objects: 100% (5/5), done. 

Writing objects: 100% (7/7), 686 bytes, done. 

Total 7 (delta 0), reused 0 (delta 0) 

Unpacking objects: 100% (7/7), done. 

To file:///path/to/repos/shared.git 
6blia7a0..bccc620 master -> master 


ee | 


15.5 3 于 非 快 过 坊村 


非 快 进 式 推送 如 果 被 滥用 就 会 成 为 项 目的 灾难 : 
` 团队 成 员 之 间 的 提交 战争 取代 了 本 应 的 相互 协作 。 
. 造成 不 必要 的 冲突 ， 为 他 人 造成 麻烦 。 


- 在 提交 历史 中 引入 包含 修补 提交 前 后 两 个 版 本 的 怪异 的 合并 提 


Git 提 供 了 至 少 两 种 方式 对 非 快 进 式 推 送 进行 限制 。 一 个 是 通过 版 
本 库 的 配置 ， 男 一 个 是 通过 版 本 库 的 钧 子 脚本 。 


将 版 本 库 的 配置 变量 receive.denyNonFastForwards 设 置 为 tue 可 以 禁 
止 任何 用 户 进 行 非 快 进 式 推送 。 下 面 的 示例 中 ， 可 以 看 到 对 一 个 已 经 预 
先 设 置 为 禁止 非 快 进 式 推送 的 版 本 库 执行 非 快 进 式 推 送 操 作 ， 将 会 被 禁 
止 ， 即 使 使 用 强制 推送 操作 也 会 被 禁止 。 


(1) 更 改 服务 器 版 本 库 /path/to/repos/shared.git 的 配置 变量 。 


$ git --git-dir=/path/to/repos/shared.git config \ 
receive.denyNonFastForwards true 


(2) 在 用 户 userl 的 工作 区 执行 重 置 操作 ， 以 便 在 后 面 执行 推送 时 





产生 非 快 进 式 推送 。 





$ git reset --hard HEAD^1 

$ git 1og --graph --oneline 
* b4f3ae0 useri1's profile. 
* 5174bf3 initial commit. 





(3) 用 户 user1 即 便 使 用 强制 推送 也 不 会 成 功 。 


在 出 错 信息 中 看 到 服务 器 端 拒绝 执行 : [remote rejected]。 





$ git push -f 
Total 0 (delta 0), reused 0 (delta 0) 
remote: error: denying non-fast-forward refs/heads/master (you should pull first) 
To file:///path/to/repos/shared.git 
! [remote rejected] master -> master (non-fast-forward) 
error: failed to push some refs to 'file:///path/to/repos/shared.git'" 








另外 一 个 方法 是 通过 钩子 脚本 进行 设置 ， 可 以 仅 对 某 些 情况 下 的 非 
快 进 式 推送 进行 限制 ， 而 不 是 不 分 青 红 虹 日 地 一 概 拒绝 。 例 如 :; 只 对 部 
分 用 户 进 行 限制 ， 而 允许 特定 用 户 执 行 非 快 进 式 推送 ， 或 者 允许 东 些 分 
文 可 以 进行 强制 提交 而 其 他 分 文 不 可 以 。 第 5 篇 第 30 章 会 介绍 Gitolite 服 
务 染 设 ， 通 过 授权 文件 “实际 上 通过 版 本 库 的 update 钩 子 脚本 实现 ) 对 
版 本 库 非 快 进 式 推 送 做 出 更 为 精细 的 授权 控制 。 








第 16 章 ”冲突 解决 

上 一 章 介绍 了 Git 协 议 ， 并 且 使 用 本 地 协议 来 模拟 一 个 远程 的 版 本 
库 ， 以 两 个 不 同 用 户 的 身份 检 出 该 版 本 库 ， 和 该 远程 版 本 库 进行 交互 
一 交换 数据 、 协 同 工 作 。 在 上 一 章 的 协同 中 只 遇 到 了 一 个 小 小 的 麻烦 
一 一 非 快 进 式 推送 ， 可 以 通过 执行 拉 回 操作 (git pull》， 成 功 完成 合并 
后 再 推送 。 








但 是 在 真实 的 运行 环境 中 ， 用 户 间 协同 并 不 总 是 会 一 帆 风 顺 ， 只 要 
有 合并 束 可 能 会 有 冲突 。 本 章 就 重点 介绍 冲突 解决 机 制 。 


16.1 拉 回 操作 中 的 合并 


为 了 降低 难度 ， 上 一 章 的 实践 中 用 户 userl 执 行 git pull 操 作 解 决 非 快 
进 式 推送 问题 似乎 非常 简单 ， 束 好 像 只 要 把 共 诗 版 本 库 中 的 最 新 提交 耻 
接 拉 回 到 本 地 ， 然 后 就 可 以 推送 了 ， 其 他 的 好 像 什 么 都 没有 发 生 一 样 。 
真 的 是 这 样 么 ? 





(1)〉 用户 user1 同 共享 版 本 库 推送 时 ， 因 为 user2 强 制 推 送 已 经 改变 
了 共享 版 本 库 中 的 提交 状态 ， 导 致 userl 推 送 失败 ， 如 图 16-1 所 示 。 


Iaster mast 
U DD 
一 一 一 一 

4 (non-fast-forward) 
用 户 userl 本 地 版 本 库 共享 版 本 库 


图 16-1 非 快 进 式 推送 被 禁止 


(2) 用 户 userl 执 行 拉 回 操作 的 第 一 阶段 ， 将 共 译 版 本 库 master 分 
支 的 最 新 提交 获取 到 本 地 ， 并 更 新 到 本 地 版 本 库 特 定 的 引用 


refs/remotes/origin/master( 人 简称 为 origin/master) ， 如 图 16-2 所 示 。 


master origin/master 、 三 master 
| 


git fetch (2) {6) 
二- 一 一 








用 户 userl 本 地 版 本 库 。 本 共享 版 本 库 


图 16-2 ”执行 获取 操作 


(3) 用 户 userl 执 行 拉 回 操作 的 第 二 阶段 ， 将 本 地 分 文 master 和 共 
享 版 本 库 本 地 跟踪 分 支 origin/master 进 行 合 并 操作 ， 如 图 16-3 所 示 。 





mastor 


origin/master master 







git merge 





共享 版 本 库 





用 户 userl 本 地 版 本 库 








图 16-3 ”执行 合并 操作 


(4) 用 户 user1l 执 行 推送 操作 ， 将 本 地 提交 推送 到 共享 版 本 库 中 ， 
如 图 16-4 所 示 。 


master™\ 














master™\ 
用 户 user1 本 地 版 本 库 ”共享 版 本 库 


图 16-4 执行 推送 操作 


实际 上 拉 回 操作 (git pull) 是 由 两 个 步骤 组 成 的 : 一 个 是 获取 操作 
(git fetch) ， 另 一 个 是 合并 操作 (git merge) ， 即 : 


git pull = git fetch + git merge 





图 16-2 示 意 的 获取 操作 看 似 很 简单 ， 实 际 上 要 到 第 19 章 介绍 远程 版 
本 库 的 章节 才能 够 讲 明 白 ， 现 在 只 需要 根据 图 示 将 获取 操作 理解 为 将 远 
程 的 共享 版 本 库 的 对 象 〈 提 交 、 里 程 碑 、 分 文 等 ) 复制 到 本 地 即 可 。 











合并 操作 是 本 章 要 介绍 的 重点 。 合 并 操作 可 以 由 拉 回 操作 (git 
pull》 隐 式 地 执行 ， 将 其 他 版 本 库 的 所 交 和 本 地 版 本 库 的 提交 进行 合 
并 。 还 可 以 针对 本 版 本 库 中 的 其 他 分 支 〈 将 在 第 18 章 中 介绍 〉 进行 显示 
的 合并 操作 ， 将 其 他 分 文 的 提交 和 当前 分 文 的 提交 进行 合并 。 





合并 操作 的 命令 行 格式 如 下 : 


git merge [选项 ...] <commit>... 





合并 操作 的 大 多 数 情况 ， 只 须 提供 一 个 <commit>《〈 提 交 ID 或 对 应 
的 引用 : 分 文 、 里 程 碑 等 ) 作为 参数 。 合 并 操作 将 <commit> 对 应 的 目录 
树 和 当前 工作 分 文 的 目录 树 的 内 容 进行 合并 ， 合 并 后 的 提交 以 当前 分 文 
的 提交 作为 第 一 个 父 提交 ， 以 <commit> 为 第 二 个 父 提交 。 合 并 操作 还 文 


持 将 多 个 <commit> 代 表 的 分 文 和 当前 分 文 进行 合并 ， 过 程 类 似 。 











默认 情况 下 ， 合 并 后 的 结果 会 目 动 提交 ， 但 是 如 打 提 供 --no-commit 
选项 ， 则 合并 后 的 结果 会 放 入 暂 存 区 ， 用 户 可 以 对 合并 结果 进行 检查 、 
更 改 ， 然 后 手动 提交 。 





合并 操作 并 非 总 会 成 功 ， 因 为 合并 的 不 同 提 交 可 能 同时 修改 了 同一 
文件 相同 区 域 的 内 容 ， 导 致 冲突 。 冲 突 会 造成 合并 操作 的 中 断 ， 冲 突 的 
文件 被 标识 ， 用 户 可 以 对 标识 为 冲突 的 文件 进行 冲突 解决 操作 ， 然 后 更 
新 暂 存 区 ， 再 提交 ， 最 终 完 成 合并 操作 。 





根据 合并 操作 是 否 过 到 冲突 ， 以 及 不 同 的 冲突 类 型 ， 可 以 分 为 以 下 
几 种 情况 : 成 功 的 自动 合并 、 逻 辑 冲 突 、 真 正 的 冲突 和 树 冲 突 。 下 面 分 


到 予以 人 N 约 


人 全 3 一 自动 合 六 


Git 的 合并 操作 非常 智能 ， 大 多 数 情 况 下 会 自动 完成 合并 。 不 管 是 
修改 不 同 的 文件 ， 还 是 修改 相同 的 文件 (文件 的 不 同位 置 ) ， 或 者 文件 


16.2.1 ”修改 不 同 的 文件 


如 果 用 户 user1 和 user2 各 自 的 本 地 提交 中 修改 了 不 同 的 文件 ， 当 一 

个 用 户 将 改动 推送 到 服务 器 后 ， 另 外 一 个 用 户 推送 就 会 遇 到 非 快 进 式 推 

送 错 误 ， 需 要 先 合并 再 推送 。 因 为 两 个 用 户 修改 了 不 同 的 文件 ， 合 并 不 
会 遇 到 麻烦 。 


在 上 一 章 的 操作 过 程 中 ， 两 个 用 户 的 本 地 版 本 库 和 共 人 至 版 本 库 可 能 
不 一 致 ， 为 了 确保 版 本 库 状 态 的 一 致 性 ， 以 便 下 面 的 实践 能 够 正常 执 
行 ， 分 别 在 两 个 用 户 的 本 地 版 本 库 中 执行 下 面 的 操作 。 





$ git fetch 
$ git reset --hard origin/master 





下 面 的 实践 中 ， 两 个 用 户 分 别 修改 不 同 的 文件 ， 其 中 一 个 用 户 要 
试 合并 操作 将 本 地 提交 和 另外 一 个 用 户 的 提交 合并 ， 有 其 体操 作 过 程 如 
Ts 


(1) 用 户 user1 修 改 team/user1.txt 文 件 ， 提 交 并 推送 到 共享 服务 
es 





$ cd /path/to/user1i/workspace/project/ 

$ echo "hack by user1 at date ”>> team/user1.txt 
$ git add -u 

$ git commit -m "update team/user1.txt" 

$ git push 





(2) 用 户 user2 修 改 team/user2.txt 文 件 ， 提 交 。 





$ cd /path/to/user2/workspace/project/ 

$ echo "hack by user2 at ‘date'’" >> team/user2.txt 
$ git add -u 

$ git commit -m "update team/user2.txt" 





(3) 用 户 user2 在 推送 的 时 候 ， 会 遇 到 非 快 进 式 推送 的 错误 而 被 终 
i 





$ git push 
To file:///path/to/repos/shared.git 
! [rejected] master -> master (non-fast-forward) 


error: failed to push some refs to 'file:///path/to/repos/shared.git'" 

To prevent you from losing history, non-fast-forward updates were rejected 
Merge the remote changes (e.g. 'git pull') before pushing again. See the 
'Note about fast-forwards' section of 'git push --help' for details. 





(4) 用 户 user2 执 行 获取 (git fetch) 操作 。 获 取 到 的 提交 更 新 到 本 
地 用 于 跟踪 共享 版 本 库 master 分 支 的 本 地 引用 origin/master 中 。 








$ git fetch 

remote: Counting objects: 7, done 

remote: Compressing objects: 100% (4/4), done. 

remote: Total 4 (delta 0), reused 0 (delta 0) 

Unpacking objects: 100% (4/4), done. 

From file:///path/to/repos/shared 
bccc620..25fce74 master -> origin/master 





(5) 用 户 user2 执 行 合并 操作 ， 完 成 目 动 合并 。 





$ git merge origin/master 
Merge made by recursive. 
team/user1.txt | x 
1 files changed, 1 insertions(+), 0 deletions(-) 





(6) 用 户 user2 推 送 合并 后 的 本 地 版 本 库 到 共享 版 本 库 。 





$ git push 

Counting objects: 12, done. 

Delta compression using up to 2 threads. 

Compressing objects: 100% (7/7), done. 

Writing objects: 100% (7/7), 747 bytes, done. 

Total 7 (delta 0), reused 0 (delta 0) 

Unpacking objects: 100% (7/7), done. 

To file:///path/to/repos/shared.git 
25fce74..0855b86 master -> master 





(7) 通过 提交 日 志 ， 可 以 看 到 成 功 合并 的 提交 及 其 两 个 父 提交 的 
关系 图 。 





git log -3 --graph --stat 

commit 0855b86678d1cf86ccdd13adaaa6e735715d6a7e 
Merge: f53acdf 25fce74 

Author: user2 <user2@moon.ossxp.com> 

Date: Sat Dec 25 23:00:55 2010 +0800 


Merge remote branch 'origin/master' 
commit 25fce74b5e73b960c42e4a463d03d462919b674d 
Author: user1 <user1iQ@sun.ossxp.com> 
Date: Sat Dec 25 22:54:53 2010 +0800 


update team/user1.txt 


team/user1.txt | 十 注 
1 files changed, 1 insertions(+), 0 deletions(-) 


commit f53acdf6a76e0552b562f5aaa4d40ff19e8e2f77 
Author: user2 <user2@moon.ossxp.com> 
Date: Sat Dec 25 22:56:49 2010 +0800 


pe Pd 
ee ed hh a eh 9 ed et i td rt 


$ 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 


update team/user2.txt 


| 
| team/user2.txt | 1 
| 1 files changed, 1 re 0 deletions(-) 


16.2.2 ”修改 相同 文件 的 不 同 区 域 


当 用 户 userl1 和 user2 在 本 地 提交 中 修改 相同 的 文件 ， 但 是 修改 的 是 
文件 的 不 同位 置 时 ， 则 两 个 用 户 的 提交 仍 可 成 功 合 并 ， 具 体操 作 过 程 如 
下 


(1) 为 确保 两 个 用 户 的 本 地 版 本 库 和 共享 版 本 库 状 态 一 致 ， 先 分 
别 对 两 个 用 户 的 本 地 版 本 库 执行 拉 回 操作 。 





$ git pull 


(2) 用 户 userl 在 自己 的 工作 区 中 修改 README 文 件 ， 在 文件 的 第 
一 行 插 入 内 容 ， 更 改 后 的 文件 内 容 如 下 。 








User1 hacked. 
Hello. 





(3) 用 户 user1 对 修改 进行 本 地 提交 并 推送 到 共 至 版 本 库 。 


$ git add -u 
$ git commit -m "User1 hack at the beginning." 
$ git push 


(4) 用 户 user2 在 自己 的 工作 区 中 修改 README 文 件 ， 在 文件 的 最 





后 插入 内 容 ， 更 改 后 的 文件 内 容 如 下 。 





Hello. 
User2 hacked. 





(5) 用户 user2 对 修改 进行 本 地 提交 。 





$ git add -u 
$ git commit -m "User2 hack at the end." 





(6) 用 户 user2 执 行 获取 (git fetch) 操作 。 获 取 到 的 提交 更 新 到 本 
地 用 于 跟踪 共享 版 本 库 master 分 支 的 本 地 引用 origin/master 中 。 








$ git fetch 
remote: Counting objects: 5, done. 
remote: Compressing objects: 100% (2/2), done. 
remote: Total 3 (delta 0), reused 0 (delta 0) 
Unpacking objects: 100% (3/3), done. 
From file:///path/to/repos/shared 

0855b86. .07e9d08 master -> origin/master 





(7) 用 户 user2 执 行 合并 操作 ， 完 成 目 动 合并 。 





$ git merge refs/remotes/origin/master 
Auto-merging README 
Merge made by recursive. 

README | 1+ 

1 files changed, 1 insertions(+), 0 deletions(-) 





(8) 用 户 user2 推 送 合并 后 的 本 地 版 本 库 到 共享 版 本 库 。 





$ git push 

Counting objects: 10, done. 

Delta compression using up to 2 threads. 
Compressing objects: 100% (4/4), done. 
Writing objects: 100% (6/6), 607 bytes, done. 


Total 6 (delta 0)， reused 3 (delta 0) 

Unpacking objects: 100% (6/6), done. 

To file:///path/to/repos/shared.git 
O07e9d08..2a67e6f master -> master 





(9) 如 果 追 溯 一 下 README 文 件 每 一 行 的 来 源 ， 可 以 看 到 分 别 是 
user1 和 user2 更 改 的 最 前 和 最 后 的 一 行 。 








$ git blame README 

07e9d082 (user1 2010-12-25 23:12:17 +0800 1) User1 hacked. 
^5174bf3 (user1 2010-12-19 15:52:29 +0800 2) Hello. 
bboc74fa (user2 2010-12-25 23:14:27 +0800 3) User2 hacked. 





16.2.3 ”同时 更 改 文件 名 和 文件 内 容 


如 果 一 个 用 户 将 文件 移动 到 其 他 目录 《或 修改 文件 名 ) ， 另 外 一 个 
用 户 针 对 重 命 名 前 的 文件 进行 了 修改 ， 还 能 够 实现 自动 合并 么 ?这 对 于 
其 他 版 本 控制 系统 可 能 是 一 个 难题 ， 例 如 Subversion 束 不 能 很 好 地 处 
理 ， 还 为 此 引入 了 一 个 “ 树 冲 突 *” 的 新 名 词 。Git 对 于 此 类 冲突 能 够 很 好 地 
处 理 ， 可 以 目 动 解决 冲突 实现 目 动 合并 ， 具 体操 作 过 程 如 下 。 














(1) 为 确保 两 个 用 户 的 本 地 版 本 库 和 共享 版 本 库 状 态 一 致 ， 先 分 
别 对 两 个 用 户 的 本 地 版 本 库 执行 拉 回 操作 。 





$ git pull 








(2) 用 户 userl 在 自己 的 工作 区 中 将 文件 README 进 行 章 合 名， 本 
地 提交 并 推送 到 共享 版 本 库 。 





cd /path/to/user1i/workspace/project/ 
mkdir doc 

git mv README doc/README. txt 

git commit -m "move document to doc/." 
git push 


份 份 从 伊人 仇 





(3) 用 户 user2 在 自己 的 工作 区 中 修改 README 文 件 ， 在 文件 的 最 
后 插入 内 容 ， 并 本 地 提交 。 








$ cd /path/to/user2/workspace/project/ 

$ echo "User2 hacked again." >> README 

$ git add -u 

$ git commit -m "User2 hack README again." 





(4) 用 户 user2 执 行 获取 (git fetch) 操作 。 获 取 到 的 提交 更 新 到 本 
地 跟 踩 共享 版 本 库 master 分 文 的 本 地 引用 origin/master 中 。 





$ git fetch 

remote: Counting objects: 5, done. 

remote: Compressing objects: 100% (2/2), done. 

remote: Total 3 (delta 0), reused 0 (delta 0) 

Unpacking objects: 100% (3/3), done. 

From file:///path/to/repos/shared 
0855b86..07e9d08 master -> origin/master 





(5) 用 户 user2 执 行 合并 操作 ， 完 成 目 动 合并 。 





$ git merge refs/remotes/origin/master 

Merge made by recursive. 
README => doc/README.txt | 0 
1 files changed, © insertions(+), 0 deletions(-) 
rename README => doc/README.txt (100%) 





(6) 用 户 user2 推 送 合并 后 的 本 地 版 本 库 到 共享 版 本 库 。 





$ git push 


Counting objects: 10, done. 

Delta compression using up to 2 threads. 

Compressing objects: 100% (5/5), done. 

Writing objects: 100% (6/6), 636 bytes, done. 

Total 6 (delta 0), reused 0 (delta 0) 

Unpacking objects: 100% (6/6), done. 

To file:///path/to/repos/shared.git 
gc51cb9..f73db10 master -> master 





(7) 使 用 -m 参 数 可 以 但 看 合并 操作 所 做 出 的 修改 。 





$ git 1og -1 -m --stat 
commit f73db106c820fgoc6d510f18ae8c67629af9c13b7 (from 887488eee19300c566c272ec84b23t 
Merge: 887488e 9c51cb9 
Author: user2 <user2@moon.ossxp.com> 
Date: Sat Dec 25 23:36:57 2010 +0800 
Merge remote branch 'refs/remotes/origin/master' 
README | 4 ---- 
doc/README ,txt | 4 十 十 十 十 
2 files changed， 4 insertions(+), 4 deletions(-) 
commit f73db106c820foc6d510f18ae8c67629af9c13b7 (from 9c51cb91bfe12654e2de1d61d7221 
Merge: 887488e 9c51cb9 
Author: user2 <user2@moon.ossxp.com> 
Date: Sat Dec 25 23:36:57 2010 +0800 
Merge remote branch 'refs/remotes/origin/master' 
doc/README ,txt | 并 二 
1 files changed, 1 insertions(+), 0 deletions(-) 


ee | 


16.3 合并 二 : 逻辑 冲突 











自动 合并 如 果 成 功 地 执行 ， 则 大 多 数 情况 下 就 意味 着 完事 大 吉 ， 但 
是 在 某 些 特殊 情况 下 ， 合 并 后 的 结果 虽然 在 Git 看 来 是 完美 的 合并 ， 实 
际 上 却 存在 着 逻辑 冲突 。 

















一 个 典型 的 逻辑 冲突 是 一 个 用 户 修改 了 一 个 文件 的 文件 名 ， 而 另外 
的 用 户 在 其 他 文件 中 引用 旧 的 文件 名 ， 这 样 的 合并 虽然 能 够 成 功 但 是 包 
含 看 逻辑 冲突 。 例 如 : 








(1) 一 个 C 语 言 的 项 目 中 存在 头 文件 hello.h， 该 头 文件 定义 了 一 些 
函数 声明 。 


(2) 用 户 userl 将 hello.h 文 件 改名 为 apih。 


(3) 用户 user2 写 了 一 个 新 的 源码 文件 foo.c 并 在 该 文件 中 包含 了 
hello.h 文 件 。 


(4) 两 个 用 户 的 提交 合并 后 ， 会 因为 源码 文件 foo.c 找 不 到 所 包含 
的 文件 hello.h 而 导致 项 目 编译 失败 。 


再 举 一 个 逻辑 冲突 的 示例 。 假 如 一 个 用 户 修改 了 函数 返回 值 而 男 外 
的 用 户 使 用 旧 的 函数 返回 值 ， 虽 然 成 功 合并 但 是 存在 逻辑 冲突 : 


(1) 函数 compare (obj1，obj2) 用 于 比较 两 个 对 象 obj1 和 obj2。 返 
回 1 代 表 比 较 的 两 个 对 象 相 同 ， 返 回 0 代 表 比 较 的 两 个 对 象 不 同 。 








(2) 用户 userl 修 改 了 该 函数 的 返回 值 ， 返 回 0 代 表 两 个 对 象 相同 ， 
返回 1 代表 obj1 大 于 obj2， 返 回 -1 则 代表 obj1 小 于 obj2。 


(3) 用 户 user2 不 知道 user1 对 该 函数 的 改动 ， 仍 以 该 函数 原 返回 值 
判断 两 个 对 象 的 异同 。 





《4) 两 个 用 户 的 提交 合并 后 ， 不 会 出 现 编译 错误 ， 但 是 软件 中 会 
潜藏 着 重大 的 Bug。 





上 面 的 两 个 逻辑 冲突 的 示例 ， 尤 其 是 最 后 一 个 非常 难以 捕捉 。 如 果 
因此 而 贬低 Git 的 自动 合并 ， 或 者 对 每 次 自动 合并 的 结果 疑 神 疑 网， 进 
而 花费 大 量 精力 去 分 析 合 并 的 结果 ， 则 是 因 咕 废 食 、 得 不 偿 失 。 一 个 好 
的 项 目 实践 是 每 个 开发 人 员 都 为 自己 的 代码 编写 可 运行 的 单元 测试 ， 项 
目 每 次 编译 时 都 要 执行 目 动 化 测试 ， 捕 捉 潜藏 的 Bug。 在 2010 年 
OpenParty 上 的 一 个 报告 中 ， 我 介绍 了 如 何在 项 目 中 引入 单元 测试 及 上 自 
动 化 集成 ， 可 以 参考 下 面 的 链接 : 

















* http:/ /www.beijing-open-party.org/topic/9 


* http://wenku.baidu.com/view/63bf7d160b4e767f5acfcef6.html 


16.4 合并 三 : 冲突 解决 


如 果 两 个 用 户 修改 了 同一 文件 的 同一 区 域 ， 则 在 合并 的 时 候 会 遇 到 
冲突 而 导致 合并 过 程 中 断 。 这 是 因为 Git 并 不 能 越 租 代 鹿 地 从 用 户 做 出 
决定 ， 而 是 把 决定 权 交 给 用 户 。 在 这 种 情况 下 ，Git 标 识 出 合并 冲突 ， 
等 得 用户 对 冲突 做 出 抉择 。 





下 面 的 实践 非常 简单 ， 两 个 用 户 都 修改 doc/README.txt 文 件 ， 在 
第 二 行 “Hello.” 的 后 面 加 上 自己 的 名 字 ， 具 体操 作 过 程 如 下 。 





(1) 为 确保 两 个 用 户 的 本 地 版 本 库 和 共享 版 本 库 状 态 一 致 ， 先 分 
别 对 两 个 用 户 的 本 地 版 本 库 执行 拉 回 操作 。 


$ git pull 


(2) 用 户 user1l 在 上 自己 的 工作 区 中 修改 dowREADME.txt 文 件 〈 仅 改 
动 了 第 二 行 ) 。 修 改 后 内 容 如 下 : 








User1L hacked. 
Hello, useri. 
User2 hacked. 
User2 hacked again. 


(3) 用 户 user1 对 修改 进行 本 地 提交 并 推送 到 共 至 版 本 库 。 





$ git add -u 


$ git commit -m "Say hello to User1," 
$ git push 





(4) 用 户 user2 在 上 自己 的 工作 区 中 修改 dowREADME.txt 文 件 〈 仅 改 
动 了 第 二 行 ) 。 修 改 后 内 容 如 下 : 








User1 hacked. 
Hello, user2. 
User2 hacked. 
User2 hacked again. 





(5) 用 户 user2 对 修改 进行 本 地 提交 。 





$ git add -u 
$ git commit -m "Say hello to user2." 





(6) 用户 user2 执 行 拉 回 操作 ， 遇 到 冲突 。 


git pull 操 作 相 当 于 git fetch 和 git merge 两 个 操作 。 





$ git pull 
remote: Counting objects: 7, done. 
remote: Compressing objects: 100% (3/3), done. 
remote: Total 4 (delta 0), reused 0 (delta 0) 
Unpacking objects: 100% (4/4), done. 
From file:///path/to/repos/shared 
f73db10..a123390 master -> origin/master 
Auto-merging doc/README .txt 
CONFLICT (content): Merge conflict in doc/README. txt 
Automatic merge failed; fix conflicts and then commit the result. 





执行 git pull 时 所 做 的 合并 操作 由 于 过 到 冲突 导致 中 断 。 来 看 看 处 于 
合并 冲突 状态 时 工作 区 和 和 暂 存 区 的 状态 。 





执行 git status 命 令 ， 可 以 从 状态 输出 中 看 到 文件 docv/README.txt 处 





于 未 合并 (冲突) 的 状态 ， 这 个 文件 在 两 个 不 同 的 提交 中 都 做 了 修改 。 





$ git status 

# On branch master 

# Your branch and 'refs/remotes/origin/master' have diverged, 
# and have 1 and 1 different commit(s) each, respectively. 

## 

# Unmerged paths : 

# (use "git add/rm <file>..." as appropriate to mark resolution) 
## 

# both modified: doc/README .txt 

# 

n 


0 changes added to commit (use "git add" and/or "git commit -a") 





那么 Git 是 如 何 记 录 合 并 过 程 及 冲突 的 呢 ? 


过 .8git 目 录 下 的 几 个 文件 进行 记录 的 ， 


实际 上 合并 过 程 是 通 


文件 .git/MERGE_HEAD 记 录 所 合并 的 提交 ID。 


. 文件 .git/ MERGE_MSG 记 录 合 并 失败 的 信息 。 


. 文件 .git/MERGE_MODE 标 识 合 并 状态 。 








» 


版 本 库 暂 存 区 中 则 会 记录 冲突 文件 的 多 个 不 同 版 本 。 可 以 使 用 git 


ls-files 命 令 查 看 : 





$ git ls-files -s 

100644 ea501534d70a13b47b3b4b85c39ab487fa6471c2 
100644 5611db505157d312e4f6fb1db2e2c5bac2a55432 
100644 036dbc5c11boagcefc8247cfoe9a3e678f8de060 
100644 430bd4314705257a53241bc1d2cb2cc30f06f5ea 
100644 a72ca0b4f2b9661d12d2a0c1456649fc074a38e3 


工 
2 
3 
0 
0 


doc/README. 
doc/README. 
doc/README. 
team/user1. 
team/user2. 


txt 
txt 
txt 
txt 
txt 





在 上 面 的 输出 中 ， 每 一 行 分 为 四 个 字段 ， 














和 SHA1 哈 和 希 值 。 第 三 个 字段 是 暂 存 区 编号 。 


前 两 个 分 别 是 文件 的 属性 
当 合并 冲突 发 生 后 ， 


会 用 


到 0 以 上 的 暂 存 区 编号。 


. 编号 为 1 的 暂 存 区 用 于 保存 冲突 文件 修改 之 前 的 副本 ， 即 冲突 双 
方 共同 的 祖先 版 本 。 可 以 用 :1: 访 问 。 





$ git show :1:doc/README. txt 
User1 hacked. 

Hello. 

User2 hacked. 

User2 hacked again. 





` 编号 为 2 的 暂 存 区 用 于 保存 当前 冲突 文件 在 当前 分 支 中 修改 的 副 
本 。 可 以 用 :2: 访 问 。 





$ git show :2:doc/README. txt 
User1 hacked. 

Hello, user2. 

User2 hacked. 

User2 hacked again. 





. 编号 为 3 的 暂 存 区 用 于 保存 当前 冲突 文件 在 合并 版 本 (分 支 ) 中 
修改 的 副本 。 可 以 用 :3: 访 问 。 





$ git show :3:doc/README. txt 
User1 hacked. 

Hello, useril. 

User2 hacked. 

User2 hacked again. 





对 暂 存 区 中 冲突 文件 的 上 述 三 个 副本 无 须 了 解 太 多 ， 这 三 个 副本 实 
际 上 是 提供 冲突 解决 工具 ， 用 于 实现 三 同文 件 合并 的 。 


工作 区 的 版 本 则 可 能 同时 包含 了 成 功 的 合并 及 冲突 的 合并 ， 其 中 冲 
突 的 合并 会 用 特殊 的 标记 〈<<<<<<<=======>>>>>>>) 进行 标识 。 查 


看 当前 工作 区 中 冲突 的 文件 : 











$ cat doc/README. txt 
User1 hacked. 
<<<<<<< HEAD 

Hello, user2. 


Hello, useri. 

>>>>>>> a123390b8936882bd53033a582ab540850b6b5fb 
User2 hacked. 

User2 hacked again. 








特殊 标识 <<<<<<< (七 个 小 于 号 ) 和 ======= (七 个 等 号 ) 之 间 的 
内 容 是 当前 分 文 所 更 改 的 内 容 。 特 殊 标 识 ======= (七 个 等 号 ) 和 


>>>>>>> (七 个 大 于 号 ) 之 间 的 内 容 是 所 合并 的 版 本 更 改 的 内 容 。 





冲突 解决 的 实质 就 是 通过 编辑 操作 ， 将 冲突 标识 符 所 标识 的 冲突 内 
容 蔡 换 为 合适 的 内 容 ， 并 去 挥 冲突 标识 和 从。 编辑 完毕 后 执行 git add 命 令 
将 文件 添加 到 和 暂 存 区 《〈 标 号 0) ， 然 后 再 提交 就 完成 了 冲突 解决 。 





当 工 作 区 处 于 合并 冲突 状态 时 ， 无 法 再 执行 提交 操作 。 此 时 有 两 个 
选择 : 放弃 合并 操作 ， 或 者 对 合并 冲突 进行 冲突 解决 操作 。 放 弃 合 并 操 
作 非 第 简单 ， 只 须 执 行 git reset 将 暂 存 区 重 置 即 可 。 下 面 重 点 介绍 如 何 进 
行 冲突 解 决 的 操作 。 有 两 个 方法 进行 冲突 解决 ， 一 个 是 对 少量 冲突 非常 
适合 的 手工 编辑 操作 ， 为 外 一 个 是 使 用 图 形 化 冲突 解决 工具 。 





16.4.1 手工 编辑 完成 冲突 解决 





先 来 看 看 不 使 用 工具 ， 直 接手 动 编辑 完成 冲突 解决 。 打 开 文 件 
doc/README.txt， 将 冲突 标识 符 所 标识 的 文字 蔡 换 为 Hello，userland 
user2.。 修 改 后 的 文件 内 容 如 下 : 








User1 hacked. 

Hello, user1 and user2. 
User2 hacked. 

User2 hacked again. 





然后 添加 到 暂 存 区 ， 并 提交 : 





$ git add -u 
$ git commit -m "Merge completed: say hello to all users." 














查看 最 近 三 次 提交 的 日 志 ， 会 看 到 最 新 的 提交 就 是 一 个 合并 提交 : 





$ git 1og --oneline --graph -3 

四 bd3ad1a Merge completed: say hello to all users. 
|\ 

| * al123390 Say hello to useri1l. 

* | 60b10f3 Say hello to user2. 

I/ 





提交 完成 后 ， 会 看 到 .git 目 录 下 与 合并 相关 的 文 
件 .giUMERGE_HEAD、.giUVMERGE_MSG、.giVUMERGE_MODE 文 件 都 
自动 删除 了 。 





如 宁 碍 看 暂 存 区 ， 会 发 现 冲 突 文 件 在 暂 存 区 中 的 三 个 副本 也 都 清除 





了 《实际 在 对 编辑 完成 的 冲突 文件 执行 git add 后 就 已 经 清除 了 ) 。 





$ git ls-files -s 


100644 463dd451d94832f196096bbcgoc9cf9f2dof82527 0 doc/VREADME .七 Xt 
100644 430bd4314705257a53241bc1d2cb2cc30f06f5ea 0 team/user1.txt 
100644 a72cag0b4f2b9661d12d2a0c1456649fc074a38e3 0 team/user2.txt 





16.4.2 图形 工具 完成 冲突 解决 


上 面 介绍 的 通过 手工 编辑 完成 冲突 解决 并 不 复杂 ， 对 于 简单 的 冲突 
古 最 快捷 的 解决 方法 。 但 是 如 果 冲 突 的 区 域 过 多 、 过 大 ， 并 且 缺 乏 原 始 
版 本 作为 参照 ， 冲 突 解决 过 程 就 会 显得 非常 的 不 便 ， 这 种 情况 下 使 用 图 
形 工具 惑 显得 非常 有 优势 。 











还 以 上 面 的 合并 冲突 为 例 介绍 使 用 图 形 工具 进行 冲突 解决 的 方法 。 
为 了 制造 一 个 冲突 ， 首 先 把 user2 辛 辛 吾 吾 完 成 的 冲突 解决 提交 回 深 ， 再 
执行 合并 重新 进入 冲突 状态 。 


(1) 将 冲突 解决 的 提交 丢弃 ， 即 强制 重 置 到 前 一 个 版 本 。 





$ git reset --hard HEAD^ 





(2) 这 时 碍 看 状态 ， 会 显示 当前 工作 分 支 的 最 新 提交 和 共享 版 本 
库 的 master 分 文 的 最 新 提交 出 现 了 偏离 





$ git status 
# On branch master 
# Your branch and 'refs/remotes/origin/master' have diverged, 


# and have 1 and 1 different commit(s) each, respectively. 
## 
nothing to commit (working directory clean) 





(3) 那么 执行 合并 操作 吧 。 冲 突 友 生 了 。 





$ git merge refs/remotes/origin/master 

Auto-merging doc/README. txt 

CONFLICT (content): Merge conflict in doc/README.txt 

Automatic merge failed; fix conflicts and then commit the result. 





下 面 就 演示 使 用 图 形 工具 如 何 解 决 冲突 。 使 用 图 形 工具 进行 冲突 解 
决 需要 事先 在 操作 系统 中 安装 相关 的 工具 软件 ， 如 : kdiff3、meld、 
tortoisemerge、araxis 等 。 而 启动 图 形 工 具 进 行 冲突 解决 也 非常 简单 ， 只 


须 执行 命令 git mergetool 即 可 。 





$ git mergetool 
merge tool candidates: opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff dit1 
Merging: 
doc/README . txt 
Normal merge conflict for 'doc/README.txt"': 
{local}: modified 
{remote}: modified 
Hit return to start merge resolution tool (kdiff3): 





运行 git mergetool 命 令 后 ， 会 显示 文 持 的 图 形 工 具 列 表 ， 并 提示 用 
户 选 择 可 用 的 冲突 解决 工具 。 默 认 会 选择 系统 中 己 经 安装 的 工具 软件 ， 
如 kdiff3。 和 直接 按 下 回 车 键 ， 自 动 打 开 kdiff3 进 入 冲突 解决 界面 。 








启动 kdiff3 后 ， 如 图 16-5 所 示 ， 上 方 三 个 窗口 由 左 至 右 显 示 冲 突 文 
件 的 三 个 版 本 ， 分 别 是 : 


暂 存 区 1 中 的 版 本 (共同 祖先 版 本 〉。 


暂 存 区 2 中 的 版 本 当前 分 文 更 改 的 版 本 )。 


暂 存 区 3 中 的 版 本 (他 人 更 改 的 版 本 )。 


.README.txt (Base) <-> ../README.txt (Local) <-> ../README.txt (Remote) - KDif3 
文件 (FE) 编辑 (E) ”目录 (D) 移动 (M) 查看 Diff(I) 合并 (M) ”窗口 (W) 设置 (S) 帮助 (H) 


加 国共 久 加 局 的 站 W=AaAv 人 全 多 要 ABCY Ols 


A (Base): doc/RFEADME txt (Base) __) B: | doc/README txt (Local) J © | doc/README txt (Remote) es 
mp line 1 编码 UTF-8 行 尾 风格 : Unix 了 line 1 编码 ，UTF-8 行 昨 风格 : Unix Ep line 1 编码 UTF-8 行 尾 风格 : Unix 
Userl hacked. Userl hacked Userl hacked 
2 | Heio 2 | FEIO LU vser2. 2 | EEIORRL vser1i! 
User2 hacked User2 hacked User2 hacked. 
4 User2 hacked again User2 hacked again. User2 hacked again 


5 5 





竹山 避 doc/READMEtxt ”| [已 修改 ] Encoding for saving:| Codec from C: UTF-8 v | 行 尾 风格: |Unix (A, B, C) v | 
] Userl ET 
? 镍 了 汪 六 再 
User2 Decked 
User2 hacked again . 


< ?> 





八 
人 
v 








NN 


图 16-5 ”kdiff3 冲 突 解 决 界面 


kdiff3 下 方 的 窗口 是 合并 后 文件 的 编辑 窗口 。 如 图 16-6 所 示 ， 点 击 
标记 为 “合并 冲突 ”的 一 行 ， 在 弹出 菜单 中 出 现 A、B、C 三 个 选项 ， 分 别 
代表 从 A、B、C 三 个 窗口 复制 相关 内 容 到 当前 位 置 。 





: .README.txt (Base) <-> .../README.txt (Local) <-> .../README.txt (Remote) - KDIW3 = O600@ 9 
文件 (E) Rt(E) RD) 移动 (M) ”查看 Diff(D) 合并 (M) ”窗口 (W) 设置 (S) ”帮助 (H) 


晶 回 其 ] 户 | 玖 | 宁 风 云 王 和 vv 企 各 全 和 手 ABCc 学 口 |- 





A (Base): | doc/README txt (Base) _ | B: [doc/README txt (Local) | C [doc/README txt (Remote) 


he line 1] 编码，UTF-8 行 尾 风 格 : Unix oR line 1 编码 ，UTF-8 行 尾 风格 : Unix ER line 1] 编码 ，UTF-8 行 尾 风格 : Unix 
Userl hacked. Userl hacked. User]l hacked. 

2 | | Haie 2 | FE LU vser2. 2 | | reio | user1il 
User2 hacked. User2 hacked. User2 hacked. 
User2 hacked again. User2 hacked again. 3 User2 hacked again. 


5 5 


输出 : doc/README txt [已 修改 ] Encoding for saving: Codec from C: UTF-8 v 行 尾 风格 : Unix (A, B, C) v 
| Userl hacked. 
< 合并 冲突 > FRR 
User2 hacked. 向 从 A 选择 行 Ctrl+1 
User2 hacked aga 四 从 B 选 择 行 Ctrl+2 


= < > 全国 一] > 





江 


图 16-6 ”kdiff3 合 并 冲突 行 的 弹出 菜单 


当 通 过 图 16-6 显 示 的 弹出 菜单 选择 了 B 和 C 后 ， 可 以 在 图 16-7 中 看 到 
在 合并 窗口 中 出 现 了 标识 B 和 C 的 行 ， 分 别 代表 user2 和 user1 对 该 行 的 修 
改 。 


[ 百 三 二 .JREADME.tXt(B6aS5e) <-> .../README.tXt (Local) <-> ../README.tXt (Remote) - KDi 三 CEGG 5 
文件 (F] 纺 编 福 (E) FD) 移动 (M) ”查看 Diff(I) 合并 (M) 窗口 (W) 设置 (5) 帮助 (H) 


品 园 上 世 尺 1! Dm== a- alelcls of-ls 


A (Base): doc/README txt kd B-: ‘doc/README txt (Local) L f= doc/README txt (Remote) 


Wp line 1 ”编码 ，UTF-8 行 尾 风格 :Unix a line 1 编码，UTF-8 行 尾 风格 : Unix op line 1] 编码 ，UTF-8 行 尾 风 格 : Unix 
Userl hacked. Userl hacked. Userl hacked. 
:ml | Heiio. 2 | Feio LU vser2. 2 | REIO LU vser1i! 
User2 hacked. User2 hacked. User2 hacked. 
User2 hacked again. ; User2 hacked again. User2 hacked again. 
5 5 


和 输出: doc/README txt [已 修改 ] Encoding for saving: Codec from C: UTF-8 v 行 尾 风格 : Unix (A, B, C) v 
Userl hacked. 
Hello, user2 . 


Hello, userl. 食 从 和 A 选 树 行 ”Ctrl+1 
User2 hacked. 


User2 hacked again VY 四 从 B 选 择 行 ”Ctri+2 
VC 从 C 选 择 行 ”Ctrl+3 


八 
| 
八 
se 
八 
八 
v 





< 
还 未 解决 的 冲突 数目 ，0( 其 中 0 项 为 空白 字符 ) 





江 


图 16-7 在 kdiff3 的 冲突 区 域 同时 选取 B 和 C 的 修改 


在 合并 窗口 进行 编辑 ， 将 “Hello，user1.” 修 改 为 “Hello，userland 


user2.”， 如 图 16-8 所 示 。 修 改 后 ， 可 以 看 到 该 行 的 标识 由 C 改 变 为 mn， 含 
义 是 该 行 是 经 过 手工 修改 的 行 。 


= ,JREADME.txt (Base) <-> .../README.txt (Local) <-> .../README.txt (Remote) - KDITT3 
文件 (F) ”编辑 (E) 目录 (D) 移动 (M) 查看 Diff(l) 合并 (M) 窗口 (W) 设置 (5) ”帮助 (H) 


可 圆 世 | 尺 口 记 人 作风 二 和 vv 人 和 人 得 he c Of 曲 昌 


A (Racse) docRFEADMFE txt (Base) sa Bi docRFADMF txt (Local) Le CC doc/RFADMF txt (Rernote) Es] 
op line 1 编码 ，UTF-8 行 尾 风 格 : Unix pp line 1 编码 ，UTF-8 行 尾 风格 ， Unix Wp line 1 编码，UTF-8 行 尾 风格 ， Unix 
Userl hacked Userl hacked Userl hacked 


2 | | He 2 | | Ha , user23 2 | | Halo ) vseril 
| User2 hacked, User2 hacked User2 hacked 


User2 hacked again User2 hacked again User2 hacked again 
5 5 





jfor saving | codecfrom C: UTF-8 v | 重 居 风格 | Unix (A, B, C) v 】 
Userl hacked 
B Hello, user2. 
Hello, Userl and user2. 
User2 hacked 
User2 hacked again. 


因 [L_ 
月 





图 16-8 ”在 kdiff3 的 冲突 区 域 编 辑 内 容 


在 合并 窗口 删除 标识 为 从 B 窗 口 引 入 的 行 “Hello，user2.”， 如 图 16-9 
所 示 。 保 存 退 出 即 完成 图 形 化 冲突 解决 。 


JREADME.txt 【Base) <-> .../README,txt (Local) <-> ,../README .txt (Remote) - KDIfT3 
文件 (EF) ”编辑 (E) ”目录 (D) 移动 (M) 查看 Diff(l) 合并 (M) 窒 口 (W) 讼 置 (S) 帮助 (H) 


吕 国 其 | 尺 加 记 | 人 网 研 和 2 全 可 多 要 BC 和 Ol-s 


A (Rasp) dorRFADMF txt (Rasp) VE Ri docRFADMF txt (1 acal) sh 和 doc/RFADMF txt (Rernore) yy 
wp line 1 编码 ，UTF-8 行 尾 风格 ， Unix me line 1 编码 ，UTF-8 行 尾 风格 Unix Se line 1 编码 ，UTF-8 行 尾 风格 ， Unix 
Userl hacked Userl hacked Userl hacked 
2 | | Halo 2 | | Helo , user28 2 | | Helio ,userll 
User2 hacked User2 hacked User2 hacked 
User2 hacked agaln User2 hacked again i; User2 hacked again 
5 5 


输 沁 全 doC/README txt a Encoding for saving | Codec from C: UTF-8 v | 符 尾 风格: |Unix (A, B,C) vj 


] Userl hacked 

m J| Hello, userl and user2. 
User2 hacked 
User2 hacked again 





六 
六 
v 
~ 
~ 
v 














图 16-9 ”完成 kdiff3 冲 突 区 域 的 编辑 


图 形 工具 保存 退出 后 ， 显 示 工 作 区 状态 ,会 看 到 冲突 已 经 解决 。 在 





工作 区 还 会 遗留 一 个 以 .orig 结 尾 的 合并 前 的 文件 副本 。 





git status 

on branch master 

Your branch and 'refs/remotes/origin/master' have diverged, 
and have 1 and 1 different commit(s) each, respectively. 


Changes to be committed: 
modified: doc/README .txt 


Untracked files: 
(use "git add <file>..." to include in what will be committed) 


亲 亲 亲 亲 亲 亲 亲 亲 半 亲 亲 亲 人 妇 


doc/README. txt .orig 





查看 暂 存 区 会 及 现 暂 存 区 中 的 冲突 文件 的 三 个 副本 都 已 经 清除 。 





$ git ls-files -s 


100644 463dd451d94832f196096bbcoc9cf9f2dof82527 0 doc/README ,七 Xt 
100644 430bd4314705257a53241bc1d2cb2cc30f06f5ea 0 team/user1.txt 
100644 a7r2ca0b4f2b9661d12d2a0c1456649fc074a38e3 0 team/user2.txt 





执行 提交 和 推送 。 





$ git commit -m "Say hello to all users." 

[master 7f7bb5e] Say hello to all users. 

$ git push 

Counting objects: 14, done. 

Delta compression using up to 2 threads. 

Compressing objects: 100% (6/6), done. 

Writing objects: 100% (8/8), 712 bytes, done. 

Total 8 (delta 0), reused 0 (delta 0) 

Unpacking objects: 100% (8/8), done. 

To file:///path/to/repos/shared.git 
a123390. .7f7bb5e master -> master 











查看 最 近 三 次 的 提交 日 志 ， 会 看 到 最 新 的 提交 古 一 个 合并 提交 。 





$ git 1og --oneline --graph -3 


大 


7f7bb5e Say hello to all users. 
| * al23390 Say hello to useri. 

* | 60b10f3 Say hello to user2. 

I/ 


二 一 


16.5 合并 四 : 树 冲 突 


如 于 一 个 用 户 将 某 个 文件 改名 ， 男 外 一 个 用 户 将 同样 的 文件 改 为 砾 
外 的 名 字 ， 当 这 两 个 用 户 的 提交 进行 合并 操作 时 ，Git 显 然 无 法 答 用 户 
做 出 裁决 ， 于 是 就 产生 了 冲突 。 这 种 因为 文件 名 修改 造成 的 冲突 ， 称 为 
树 冲 突 。 这 种 树 冲突 的 解决 方式 比较 特别 ， 因 此 专题 介绍 


仍旧 使 用 前 面 的 版 本 库 进 行 此 次 实践 。 为 确保 两 个 用 户 的 本 地 版 本 
库 和 共享 版 本 库 状 态 一 致 ， 先 分 别 对 两 个 用 户 的 本 地 版 本 库 执 行 拉 回 操 
作 。 





$ git pull 





下 面 殊 分别 以 两 个 用 户 的 里 份 执行 提交 ， 将 同样 的 一 个 文件 改 为 不 
同 的 文件 名 ， 制 造 一 个 树 冲 突 ， 具 体操 作 过 程 如 下 。 


(1) 用 户 user1 将 文件 dowREADME.txt 改 名 为 readme.txt， 提 交 并 推 
送 到 共享 版 本 库 。 





$ cd /path/to/user1i/workspace/project 

$ git mv doc/README.txt readme.txt 

$ git commit -m "rename doc/README.txt to readme.txt" 
[master 615c1ff] rename doc/README.txt to readme ,txXt 
1 files changed, © insertions(+), 0 deletions(-) 
rename doc/README.txt => readme.txt (100%) 

$ git push 

Counting objects: 3, done. 

Delta compression using up to 2 threads. 

Compressing objects: 100% (2/2), done. 


Writing objects: 100% (2/2), 282 bytes, done. 

Total 2 (delta 0), reused 0 (delta 0) 

Unpacking objects: 100% (2/2), done. 

To file:///path/to/repos/shared.git 
7f7bb5Se..615c1iff master -> master 





(2) 用 户 user2 将 文件 dowREADME.txt 改 名 为 README， 并 做 本 地 





$ cd /path/to/user2/workspace/project 
$ git mv doc/README.txt README 
$ git commit -m "rename doc/README.txt to README" 
[master 20180eb] rename doc/README.txt to README 
1 files changed, © insertions(+), 0 deletions(-) 
rename doc/README.txt => README (100%) 





(3) 用 户 user2 执 行 git pull 操 作 ， 遇 到 合并 冲突 。 





$ git pull 
remote: Counting objects: 3, done. 
remote: Compressing objects: 100% (2/2), done. 
remote: Total 2 (delta 0), reused 0 (delta 0) 
Unpacking objects: 100% (2/2), done. 
From file:///path/to/repos/shared 
7f7bb5e. .615c1ff master -> origin/master 
CONFLICT (rename/rename): Rename "doc/README.txt"->"README" in branch "HEAD" rename 
Automatic merge failed; fix conflicts and then commit the result. 








因为 两 个 用 户 同 时 更 改 了 同一 文件 的 文件 名 并 且 改 成 了 不 同 的 名 
字 ， 于 是 引发 冲突 。 此 时 查看 状态 会 看 到 : 








$ git status 

# On branch master 

# Your branch and 'refs/remotes/origin/master' have diverged, 
# and have 1 and 1 different commit(s) each, respectively. 


# 

# Unmerged paths: 

# (use "git add/rm <file>..." as appropriate to mark resolution) 
# 

# added by us: README 

# both deleted: doc/README. txt 

# added by them: readme. txt 

## 


no _ changes added to commit (use "git add" and/or "git commit -a") 





此 时 查看 一 下 用 户 user2 本 地 版 本 库 的 暂 存 区 ， 可 以 看 到 因为 冲突 在 
编写 为 1、2、3 的 暂 存 区 出 现 了 相同 SHA1 哈 希 值 的 对 象 ， 但 是 文件 名 各 
不 相同 。 








$ git ls-files -s 


100644 463dd451d94832f196096bbcgoc9cf9f2dof82527 2 README 

100644 463dd451d94832f196096bbcgoc9cf9f2dof82527 1 doc/README ,七 Xt 
100644 463dd451d94832f196096bbcgoc9cf9f2dof82527 3 readme ,txt 
100644 430bd4314705257a53241bc1d2cb2cc30f06f5ea 0 team/useri1.txt 
100644 a7r2ca0b4f2b9661d12d2a0c1456649fc074a38e3 0 team/user2.txt 








其 中 在 暂 存 区 1 中 是 改名 之 前 的 dowREADME.txt， 在 和 暂 存 区 2 中 是 
用 户 user2 改 名 后 的 文件 名 README， 而 和 暂 存 区 3 是 其 他 用 户 (user1) 改 
名 后 的 文件 readme.txt。 





此 时 的 工作 区 中 存在 两 个 相同 的 文件 README 和 readme.txt 分 别 是 
用 户 user2 和 user1 对 dowREADME.txt 重 命名 之 后 的 文件 。 





$ ls -1 readme.txt README 
-rw-r--r-- 1 jiangxin jiangxin 72 12 月 27 12:25 README 
-rw-r--r-- 1 jiangxin jiangxin 72 12 月 27 16:53 readme.txt 























16.5.1 手工 操作 解决 树 冲 突 





这 时 user2 应 该 和 user1 了 商量 一 下 到 底 应 该 将 该 文件 改 成 什么 名 字 。 
如 果 双 方 最 终 确 认 应 该 采用 user2 重 命名 的 名 称 ， 则 user2 应 该 进行 下 面 


的 操作 完成 冲突 解决 ， 具 体操 作 过 程 如 下 。 
(1) 删除 文件 readme.txt。 


在 执行 git rm 操作 过 程 时 会 弹出 三 条 警告 ， 说 共有 三 个 文件 待 合 
并 。 





$ git rm readme ,txt 

README: needs merge 
doc/README .txt: needs merge 
readme .txt: needs merge 

rm 'readme.txt' 





(2) 删除 文件 doc/README .txt。 


执行 删除 过 程 ， 弹 出 的 警告 少 了 一 条 ， 因 为 前 面 的 删除 操作 已 经 将 
一 个 冲突 文件 撤 出 暂 存 区 了 。 





$ git rm doc/README.txt 
README: needs merge 
doc/README .txt: needs merge 
rm 'doc/README .txt' 





(3) 添加 文件 README。 





$ git add README 








(4) 这 时 查看 一 下 和 暂 存 区 ， 会 发 现 所 有 文件 都 在 暂 存 区 0 中 。 





$ git ls-files -s 
100644 463dd451d94832f1960696bbcOc9cf9f2d0f82527 0 README 
100644 430bd4314705257a53241bc1d2cb2cc30f06f5ea 0 team/user1.txt 


100644 a72cagb4f2b9661d12d2a0c1456649fc074a38e3 0 team/user2.txt 








$ git commit -m "fixed tree conflict." 
[master e82187e] fixed tree conflict. 











(6) 查看 一 下 最 近 三 次 提交 日 志 ， 看 到 最 新 的 提交 是 一 个 合并 提 





$ git log --oneline --graph -3 -m --stat 


上 e82187e (from 615c1ff) fixed tree conflict. 

|\ 

| | README | 4 二 + 二 十 

| | readme.txt | 4 ---- 

| | 2 files changed, 4 insertions(+), 4 deletions(-) 
| * 615c1iff rename doc/README.txt to readme,.txt 

| | doc/README.txt | A a 

| | readme.txt | 4 十 二 十 十 

| | 2 files changed, 4 insertions(+), 4 deletions(-) 
* | 20180eb rename doc/README.txt to README 

I/ 

| README | 4 ++++ 

| doc/README. txt | 4 二 

| 


2 files changed, 4 insertions(+), 4 deletions(-) 





16.5.2 ”交互 式 解 决 树 冲 突 


树 冲突 虽然 不 能 像 文 件 冲突 那样 使 用 图 形 工具 进行 冲突 解决 ， 但 还 
是 可 以 使 用 git mergetool 命 令 ， 通 过 交互 式 问 答 快 速 解决 此 类 冲突 。 


首先 将 user2 的 工作 区 重 置 到 前 一 次 提交 ， 再 执行 git merge 引 发 树 冲 


(1) 重 置 到 前 一 次 提交 。 





$ cd /path/to/user2/workspace/project 

$ git reset --hard HEAD^ 

HEAD is now at 20180eb rename doc/README.txt to README 
$ git clean -fd 





(2) 执行 git merge 引 发 树 冲突 。 





$ git merge refs/remotes/origin/master 

CONFLICT (rename/rename): Rename "doc/README.txt"->"README" in branch "HEAD" rename 
Automatic merge failed; fix conflicts and then commit the result. 

$ git status -s 

AU README 

DD doc/README. txt 

UA readme.txt 





上 面 的 操作 所 引发 的 树 冲突 ， 可 以 执行 git mergetool 命 令 进 行 交 互 
式 冲 突 解决 ， 会 如 下 逐一 提示 用 户 进 行 选择 。 


(1) 执行 git mergetool 命 令 。 忽 略 其 中 的 提示 和 警告 。 





$ git mergetool 
merge tool candidates: opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff dit1 
Merging: 

doc/README . txt 

README 

readme. txt 

mv: 无 法 获取 "doc/README .txt" 的 文件 状态 (stat): 没有 那个 文件 或 目录 

cp: 无 法 获取 "./doc/README .txt .BACKUP.13869.txt" 的 文件 状态 (stat ) : 没有 那个 文件 或 
mv: 无 法 将 " ,merge_file_I3gfzy" 移动 至 " ,/doc/README .txt .BASE.13869.txt": 没有 那个 文件 
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(2) 询问 对 文件 dowREADME.txt 的 处 理 方式 。 输 入 d 选 择 将 该 文 
件 删除 。 





Deleted merge conflict for "doc/VREADME ,txt ' : 
{local}: deleted 


{remote}: deleted 
Use (m)odified or (d)eleted file, or (a)bort? d 





(3) 询问 对 文件 README 的 处 理 方式 。 输 入 c 选 择 将 该 文件 保留 
(创建 )。 





Deleted merge conflict for "README ' : 
{local}: created 
{remote}: deleted 
Use (c)reated or (d)eleted file, or (a)bort? c 





(4) 询问 对 文件 readme.txt 的 处 理 方式 。 输 入 d 选 择 将 该 文件 删 


水 o 





Deleted merge conflict for "readme ,txt ' : 
{local}: deleted 
{remote}: created 

Use (c)reated or (d)eleted file, or (a)bort? d 








(5) 俘 看 当前 状态 ， 只 有 一 些 尚 未 清理 的 临时 文件 ， 而 冲突 已 经 
解决 。 





$ git status -s 
?7? .merge_file I3gfzy 
?3?3 README.orig 








$ git commit -m "fixed tree conflict." 
[master e070bc9] fixed tree conflict. 





(7) 问 共 胖 服 务 器 推送 。 


一 


$ git push 

Counting objects: 5, done. 

Delta compression using up to 2 threads. 

Compressing objects: 100% (3/3), done. 

Writing objects: 100% (3/3), 457 bytes, done. 

Total 3 (delta 0), reused 0 (delta 0) 

Unpacking objects: 100% (3/3), done. 

To file:///path/to/repos/shared.git 
615c1ff..e070bc9 master -> master 


Ce | 


16.6 合并 策略 








Git 合 并 操作 支持 很 多 合并 策略 ， 默 认 会 选择 最 适合 的 合并 集 略 。 
例如 ， 和 一 个 分 文 进行 合并 时 会 选择 recursive 合 并 策略 ， 当 和 两 个 或 两 
个 以 上 的 其 他 分 支 进行 合并 时 采用 octopus 合 并 策略 。 可 以 通过 传递 参数 
使 用 指定 的 合并 集 略 ， 命 令 行 如 下 : 


git merge [-s <strategy>] [-X <strategy-option>] <commit>... 





其 中 参数 -s 用 于 设 定 合 并 策略 ， 参 数 -X 用 于 为 押 选 的 合并 策略 提供 
附加 的 参数 。 


(1) resolve 


该 合并 策略 只 能 用 于 合并 两 个 头 《“ 即 当前 分 文 和 另外 的 一 个 分 


< 


文 ) ， 使 用 三 向 合并 全 略 。 这 个 合并 集 略 被 认为 是 最 安全 、 最 快 的 合并 
打上 略 。 


(2) recursive 


该 合并 策略 只 能 用 于 合并 两 个 头 〈 即 当前 分 支 和 另外 的 一 个 分 
支 ) ， 使 用 三 向 合并 策略 。 这 个 合并 策略 是 合并 两 个 头 指针 时 的 默认 合 


当 合并 的 头 指针 拥有 一 个 以 上 的 祖先 的 时 候 ， 会 针对 多 个 公共 祖先 
创建 一 个 合并 的 树 ， 并 以 此 作为 三 向 合并 的 参照 。 这 个 合并 策略 被 认为 
可 以 实现 冲突 的 最 小 化 ， 而 且 可 以 发 现 和 处 理由 于 重 命 名 导致 的 合并 六 


气 驻 


人 
9° 





这 个 合并 策略 可 以 使 用 下 列 选 项 。 


”OUTS 


在 遇 到 冲突 的 时 候 ， 选 择 我 们 的 版 本 《当前 分 文 的 版 本 ) ， 而 忽略 
他 人 的 版 本 。 如 果 他 人 的 改动 和 本 地 改动 不 冲突 ， 会 将 他 人 的 改动 合并 
进来 。 


不 要 将 此 模式 和 后 面 介 绍 的 单纯 的 ours 合 并 策略 相 混 请 。 后 面 介 绍 
的 ours 合 并 宋 略 直接 丢弃 其 他 分 文 的 变更 ， 无 论 冲 突 与 否 。 


thelts 


和 ours 选 项 相反 ， 遇 到 冲突 时 选择 他 人 的 版 本 ， 丢 茎 我 们 的 版 本 。 


Subttee[=patb] 


这 个 选项 使 用 子 树 合并 策略 ， 比 下 面 介绍 的 subtree〈 子 树 合并 ) 策 
略 的 定制 能 力 更 强 。 下 面 的 subtree 合 并 策略 要 对 两 个 树 的 目录 移动 进行 





猜测 ， 而 recursive 合 并 策略 可 以 通过 此 参数 直接 对 子 树 目 录 进 行 设置 。 
(3) octopus 


可 以 合并 两 个 以 上 的 头 指 针 ， 但 是 拒绝 执行 需要 手动 解决 的 复杂 合 
并 。 主 要 的 用 途 是 将 多 个 主题 分 文 合并 到 一 起 。 这 个 合并 策略 是 对 三 个 
及 三 个 以 上 的 头 指针 进行 合并 时 的 默认 合并 策略 。 


(4) ours 


可 以 合并 任意 数量 的 头 指 针 ， 但 是 合并 的 结果 总 是 使 用 当前 分 支 的 
内 容 ， 丢 弃 其 他 分 文 的 内 容 。 





(5) subtree 


这 是 一 个 经 过 调整 的 recursive 策 略 。 当 合并 树 A 和 B 时 ， 如 果 B 和 A 
的 一 个 子 树 相 同 ，B 首 先进 行 调整 以 匹配 A 的 树 的 结构 ， 以 免 两 棵 树 在 
同一 级 别 进行 合并 。 同 时 也 针对 两 棵 树 的 共同 祖先 进行 调整 。 





关于 子 树 合并 会 在 第 4 篇 的 第 24 章 “ 子 树 合并 ”中 详细 介绍 


16.7 合并 相关 的 设置 





可 以 通过 git config 命 令 设置 与 合并 相关 的 配置 变量 ， 对 合并 进行 配 
置 。 下 面 是 一 些 常用 的 设置 。 


(1) merge.conflictstyle 


该 配置 变量 定义 冲突 文件 中 冲突 的 标记 风格 ， 有 两 个 可 用 的 风格 ， 
默认 的 “merge” 或 “diff3”。 





默认 的 “merge” 风 格 使 用 标准 的 冲突 分 界 符 
(<<<<<<<=======>>>>>>>) 对 冲突 内 容 进 行 标 识 ， 其 中 的 两 个 文字 


块 分 别 是 本 地 的 修改 和 他 人 的 修改 。 





如 果 使 用 “diff3” 风 格 ， 则 会 在 冲突 中 出 现 三 个 文字 块 ， 分 别 是 : 


<<<<<<< 和 | 川 之 间 的 本 地 更 改版 本 、l 和 ======= 之 间 的 原始 〈 共 同 
祖先 ) 版 本 和 ======= 和 >>>>>>> 之 间 的 他 人 和 更改 的 版 本 。 例 如 





User1 hacked. 

<<<<<<< HEAD 

Hello, user2. 

||||11|| merged common ancestors 
Hello. 


Hello, useri. 

>>>>>>> a123390b8936882bd53033a582ab540850b6b5fb 
User2 hacked. 

User2 hacked again. 


ee | 


(2) merge.tool 


设 定 执行 git mergetool 进 行 冲突 解决 时 调用 的 图 形 化 工具 。 配 置 变 
量 merge.tool 可 以 设置 为 如 下 内 置 支持 的 工 
有 具 : “kdiff3”、“tkdiff”、“meld”、“xxdiff”、“emerge”、“vimdiff”、“gvimc 





$ git config --global merge.tool kdiff3 





如 果 将 merge.tool 设 置 为 其 他 值 ， 则 使 用 上 自 定义 工具 进行 冲突 解 
决 。 自 定义 工具 需要 通过 mergetool.<tool>.cmd 对 自 定义 工具 的 命令 行进 





行 设置 。 
(3) mergetool.<tool>.path 


如 果 git mergetool 支 持 的 冲突 解决 工具 安装 在 特殊 位 置 ， 可 以 使 用 
mergetool.<tool>.path 对 工具 <tool> 的 安装 位 置 进行 设置 。 例 如 : 





$ git config --global mergetool.kdiff3.path /path/to/kdiff3 





(4) mergetool.<tool>.cmd 





如 果 所 用 的 冲突 解决 工具 不 在 内 置 的 工具 列表 中 ， 还 可 以 使 用 
mergetool.<tool>.cmd 对 上 自 定 义工 具 的 命令 行进 行 设置 ， 同 时 要 将 





merge.tool 设 置 为 <tool>。 


目 定义 工 其 的 命令 行 可 以 使 用 Shell 变 量 。 例 如 : 





$ git config --global merge.tool mykdiff3 

$ git config --global mergetool.mykdiff3.cmd '/usr/bin/kdiff3 
-L1 "$MERGED (Base)" -L2 "$MERGED (Local)" -L3 "$MERGED (Remote)" 
--auto -0 "$MERGED" "$BASE™" "$LOCAL" "$REMOTE"” 





(5) merge.log 


是 否 在 合并 提交 的 提交 说 明 中 包含 合并 提交 的 概要 信息 。 默 认为 


false。 


第 17 章 ”Git 里程 碑 


里 程 碑 即 Tag， 是 人 为 对 提交 进行 的 命名 。 这 和 Git 的 提交 ID 是 否 太 
长 无 关 ， 使 用 任何 数字 版 本 号 无 论 长 短 ， 都 没有 使 用 一 个 直观 的 表意 的 
字符 串 来 得 方便 。 例 如 : 用 里 程 碑 名 称 “v2.1” 对 应 于 软件 的 2.1 发 布 版 本 
就 比 使 用 提交 ID 要 直观 得 多 。 








对 于 里 程 碑 ， 实 际 上 我 们 并 不 陌生 ， 在 第 2 篇 的 “第 10 章 Git 基 本 操 
作 ” 中 ， 就 介绍 了 使 用 里 程 碑 来 对 工作 进度 “留影 ”纪念 ， 并 使 用 git 
describe 命 令 显 示 里 程 碑 和 提交 ID 的 组 合 来 代表 软件 的 版 本 写 。 本 划 将 
详细 介绍 里 程 碑 的 创建 、 删 除 和 共享 ， 还 会 介绍 里 程 碑 存在 的 三 种 不 同 
形式 : 轻 量 级 里 程 碑 、 带 注释 的 里 程 碑 和 带 签 名 的 里 程 碑 。 














接 下 来 的 三 章 ， 将 对 一 个 名 为 “Hello World” 的 示例 版 本 库 进行 研 
究 ， 这 个 版 本 库 不 需要 我 们 从 头 建立 ， 可 以 直接 从 Github 1 上 克隆 。 先 
使 用 下 面 的 方法 在 本 地 创建 一 个 镜像 ， 用 作 本 地 用 户 的 共享 版 本 库 。 


. 进入 本 地 版 本 库 根 目录 下 。 


$ mkdir -p /path/to/repos/ 
$ cd /path/to/repos/ 


" 从 Github 上 镜像 hello-wotld.git 版 本 库 。 


如 末 Git 是 1.6.0 或 更 新 的 版 本 ， 可 以 使 用 下 面 的 命令 建立 版 本 库 镜 
像 。 





$ git clone --mirror git://github.com/ossxp-com/hello-world.git 





否则 使 用 下 面 的 命令 建立 版 本 库 镜 像 。 





$ git clone --bare \ 
git://github.com/ossxp-com/hello-world.git hello-world.git 





完成 上 面 的 操作 后 ， 就 在 本 地 建立 了 一 个 裸 版 本 
库 /path/to/reposmhello-world.git。 接 下 来 用 户 user1 和 user2 分 别 在 各 目的 工 
作 区 元 隆 这 个 裸 版 本 库 。 使 用 如 下 命令 即 可 : 





$ git clone file:///path/to/repos/hello-world.git \ 
/path/to/user1i/workspace/hello-world 
$ git clone file:///path/to/repos/hello-world.git \ 
/path/to/user2/workspace/hello-world 
$ git --git-dir=/path/to/user1i/workspace/hello-world/ .git \ 
config user.name user1 
$ git --git-dir=/path/to/user1i/workspace/hello-world/.git \ 
config user.email user1iQ@sun.ossxp.com 
$ git --git-dir=/path/to/user2/workspace/hello-world/ .git \ 
config user.name user2 
$ git --git-dir=/path/to/user2/workspace/hello-world/ .git \ 
config user.email user2@moon.ossxp.com 





[1] https://github.com/ossxp-com/hello-wotrld/ 


17.1 显示 里 程 碑 


里 程 碑 可 以 使 用 git tag 命 令 来 显示 ， 里 程 碑 还 可 以 在 其 他 命令 的 输 
出 中 出 现 ， 下 面 分 别 对 这 些 命令 加 以 介绍 。 


1. 命 令 git tag 





不 带 任何 参数 执行 gittag 命 令 ， 即 可 显示 当前 版 本 库 的 里 程 碑 列 
表 。 





$ cd /path/to/user1i/workspace/hello-world 
$ git tag 

jx/v1.0 

jx/v1. 
jx/v1. 
jx/v1. 
jx/v1. 
jx/Vv2. 
jx/v2. 
jx/v2. 
jx/v2. 


-i1i8n 


0 
工 
2 
3 
0 
工 
2 
3 





里 程 碑 创 建 的 时 候 可 能 包含 一 个 说 明 。 在 显示 里 程 碑 的 时 候 同 时 显 


示 说 明 ， 使 用 -n<num> 参 数 ， 显 示 最 多 <num> 行 里 程 碑 的 说 明 。 





$ git tag -ni 

jx/v1.0 Version 1.0 

jx/v1.0-i1i8n i1i8n Support for vi1.0 

jx/v1.1 Version 1.1 

jx/v1.2 Version 1.2: allow spaces in username. 

jx/v1.3 Version 1.3: Hello world speaks in Chinese now. 
jx/v2.0 Version 2.0 

jx/v2.1 Version 2.1: fixed typo. 

jx/v2.2 Version 2.2: allow spaces in username. 

jx/v2.3 Version 2.3: Hello world speaks in Chinese now. 


还 可 以 使 用 通配符 对 输出 进行 过 小 。 只 显示 名 称 和 通配符 相符 的 里 





$ git tag -1 jx/v2* 
jx/v2.0 
jx/v2.1 
jx/v2.2 
jx/V2.3 





2. 命 令 git log 


在 查看 日 志 时 使 用 参数 --decorate 可 以 看 到 提交 对 应 的 里 程 碑 及 其 他 
引用 。 





$ git log --oneline --decorate 
3e6070e (HEAD, tag: jx/v1.0, origin/master, origin/HEAD, master) Show version. 
75346b3 Hello world initialized. 





3. 命 令 git describe 


使 用 命令 git describe 将 提交 显示 为 一 个 易 记 的 名 称 。 这 个 易 记 的 名 
称 来 自 于 建立 在 该 提交 上 的 里 程 碑 ， 知 该 提交 没有 里 程 碑 则 使 用 该 提交 
历史 版 本 上 的 里 程 碑 并 加 上 可 理解 的 寻 址 信息 。 


. 如 果 该 提交 恰好 被 打上 一 个 里 程 碑 ， 则 显示 该 里 程 碑 的 名 字 。 





$ git describe 

jx/v1.0 

$ git describe 384f1eg0 
jx/Vv2.2 





: 若 提交 没有 对 应 的 里 程 碑 ， 但 是 在 其 祖先 版 本 上 建 有 里 程 碑 ， 则 
使 用 类 似 --g 的 格式 显示 。 


其 中 <tag> 是 最 接近 的 祖先 提交 的 里 程 碑 名 字 ，<num> 是 该 里 程 碑 


和 提交 之 间 的 距离 ，<commit> 是 该 提交 的 精简 提交 ID 。 





$ git describe 610e78fc95bf2324dc5595fa684e08e1089f5757 
jx/v2.2-1-g610e78f 





如 果 工 作 区 对 文件 有 修改 ， 还 可 以 通过 后 级 -dirty 表 示 出 来 。 





$ echo hacked >> README; git describe --dirty; git checkout -- README 
jx/v1.0-dirty 





沾 


:如果 提交 本 身 没 有 包含 里 程 碑 ， 可 以 通过 传递 --always 参 数 显 示 精 


简 提 交 ID， 否 则 会 出 错 。 





$ echo hacked >> README; git describe --dirty; git checkout -- README 
jx/v1.0-dirty 





命令 git describe 是 非 第 有 用 的 命令 ， 可 以 将 该 命令 的 输出 用 作 软 件 
的 版 本 号 。 在 此 之 前 曾经 演示 过 这 个 应 用 ， 马 上 还 会 看 到 。 


4. 命 令 git name-rev 


命令 git name-rev 和 和 git describe 类 似 ， 会 显示 提交 ID 及 其 对 应 的 一 个 


引用 。 默 认 优先 使 用 分 文 名 ， 除 非 使 用 --tags 参 数 。 还 有 一 个 显赫 的 不 


同 就 是 ， 如 果 提 交 上 没有 相对 应 的 引用 ， 则 会 使 用 最 新 提交 上 的 引用 名 
称 并 加 上 同 后 回溯 的 符号 ~<num>。 


* 默认 优先 显示 分 支 名 。 





$ git name-rev HEAD 
HEAD master 





` 使 用 --tags 优 先 使 用 里 程 碑 。 





之 所 以 在 对 应 的 里 程 碑 引用 名 称 后 面 加 上 后 绥 ^0， 是 因为 该 引用 指 
回 的 是 一 个 tag 对 象 而 非 提 区。 用 ^0 后 绥 指 问 对 应 的 提交 。 





$ git name-rev HEAD --tags 
HEAD tags/jx/v1.0^0 





. 如 果 提 交 上 没有 对 应 的 引用 名 称 ， 则 会 使 用 新 提交 上 的 引用 名 称 
并 加 上 后 如 级 ~ 后 级 的 含义 是 早 第 第 个 祖先 提交 六 





$ git name-rev --tags 610e78fc95bf2324dc5595fa684e08e1089f5757 
610e78fc95bf2324dc5595fa684e08e1089f5757 tags/jx/v2.3~1 





` 命令 git name-rev 可 以 对 标准 输入 中 的 提交 ID 进 行政 号， 使 用 管道 


符号 对 前 一 个 命令 的 输出 进行 改写 ， 会 显示 神奇 的 效果 。 





$ git log --pretty=oneline origin/helper/master | \ 

git name-rev --tags --stdin 
bb4fef88fee435bfac04b8389cf193d9c04105a6 (tags/jx/v2.3^0) Translate for Chinese. 
610e78fc95bf2324dc5595fa684e08e1089f5757 (tags/jx/v2.3~1) Add I18N support. 
384f1e0d5106c9c6033311a608b91c69332feg0a8 (tags/jx/v2.2^0) Bugfix: allow spaces in Us 
e5e62107f8f8d0a5358c3aff993cf874935bb7fb (tags/jx/v2.1^0) fixed typo: -help to --hel 


5d7657b2f1a8e595c01c812dd5b2f67eal133f456 (tags/jx/v2.0^0) Parse arguments Using getrc 
3e6070eb2062746861b20e1e6235fed6f6d15609 (tags/jx/v1.0^0) Show version. 
75346b3283da5d8117f3fe66815f8aaaf5387321 (tags/jx/v1.0~1) Hello world initialized. 


zi 


17.2 ”创建 里 程 碑 


创建 里 程 碑 依然 是 使 用 git tag 命 令 。 创 建 里 程 碑 的 用 法 有 以 下 几 
种 : 









































用 法 1: git tag <tagname> [<commit>] 
用 法 2: git tag -a <tagname> [<commit>] 
用 法 3: git tag -m <msg> <tagname> [<commit>] 
用 法 4: git tag -s <tagname> [<commit>] 
用 法 5: git tag -u <key-id> <tagname> [<commit>] 














"用 法 1 是 创 建 轻 量 级 里 程 碑 。 


用 法 2 和 用 法 3 相同 ， 都 是 创建 带 说 明 的 里 程 碑 。 其 中 用 法 3 直接 
通过 -m 参 数 提供 里 程 碑 创建 说 明 。 


. 用 法 4 和 用 法 5 相同 ， 都 是 创建 带 GnuPG 签 名 的 里 程 碑 。 其 中 用 法 
5 用 -u 参 数 选 择 指定 的 私 钥 进行 签名 。 


创建 里 程 碑 需要 输入 里 程 碑 的 名 字 () 和 一 个 可 选 的 提交 
ID 〈() 。 





如 果 没 有 提供 提交 ID， 则 基于 头 指 针 HEAD 创 建 里程 丰 。 


17.2.1 轻 量 级 里 程 碑 


轻 量 级 里 程 碑 最 简单 ， 创 建 时 无 须 输 入 描述 信息 。 我 们 来 看 看 如 何 
创建 轻 量 级 里 程 碎 ; 


(1) 先 创 建 一 个 空 提交 





$ git commit --allow-empty -m "blank commit." 
[master 60a2f4f] blank commit. 





(2) 在 刚刚 创建 的 空 提 交 上 创建 一 个 轻 量 级 里 程 碑 ， 名 为 mytag。 


省 略 了 <commit> 参 数 ， 相 当 于 在 HEAD 上 即 最 新 的 空 提交 上 创建 里 





$ git tag mytag 





(3) 查看 里 程 碑 ， 可 以 看 到 该 里 程 碑 已 经 创建 。 





$ git tag -1 my* 
mytag 





当 创 建 了 里 程 碑 mytag 后 ， 会 在 版 本 库 的 .git/refs/tags 目 录 下 创建 一 
个 新 文件 。 


. 查看 一 下 这 个 引用 文件 的 内 容 ， 会 发 现 是 一 个 40 位 的 SHA1 哈 项 


值 。 





$ cat .git/refs/tags/mytag 
60a2f4f31e5dddd777c6ad37388fe6e5520734cb 





用 git cat-file 命 令 检 查 轻 量 级 里 程 碑 指向 的 对 象 。 轻 量 级 里 程 碑 实 


际 上 指向 的 是 一 个 提交 。 





$ git cat-file -t mytag 
commit 





` 查看 该 提交 的 内 容 ， 发 现 就 是 刚刚 进行 的 空 提交 。 





$ git cat-file -p mytag 

tree 1d902fedc4eb732f17e50f111dcecb638f10313e 

parent 3e6070eb2062746861b20e1e6235fed6f6d15609 

author USser1 <USser1lQ@sun,.ossxp.com> 1293790794 +0800 
committer User1 <User1lQ@sun,ossxp.com> 1293790794 +0800 
blank commit. 





2. 轻 量 级 里 程 碑 的 缺点 





轻 量 级 里 程 碑 的 创建 过 程 没有 记录 ， 因 此 无 法 知道 是 谁 创建 的 里 程 
碑 ， 何 时 创建 的 里 程 碑 。 在 团队 协同 开发 时 ， 尽 量 不 要 采用 此 种 偷懒 的 
方式 创建 里 程 碑 ， 而 是 采用 后 两 种 方式 。 











还 有 git describe 命 令 默认 不 使 用 轻 量 级 里 程 碑 生成 版 本 描述 字符 
Es 


` 执行 git desctibe 命 令 ， 发 现 生 成 的 版 本 描述 字符 串 ， 使 用 的 是 前 
一 个 版 本 上 的 里 程 碑 名 称 。 





$ git describe 
jx/v1.0-1-g60a2f4f 





. 使 用 --tags 参 数 ， 也 可 以 将 轻 量 级 里 程 碑 用 作 版 本 描述 符 。 





$ git describe --tags 
mytag 





17.2.2 ”和 带 说 明 的 里 程 碑 


币 说 明 的 里 程 碑 ， 就 是 使 用 参数 -a 或 -m<msg> 调 用 git tag 命 令 ， 在 
创建 里 程 碑 的 时 候 提供 一 个 关于 该 里 程 碑 的 说 明 。 下 面 来 看 看 如 何 创 建 
之 说 明 的 里 程 碑 : 


(1) 还 是 先 创 建 一 个 空 提交 





$ git commit --allow-empty -m "blank commit for annotated tag test." 
[master 8a9f3d1] blank commit for annotated tag test. 





(2) 在 刚刚 创建 的 空 提 交 上 创建 一 个 带 说 明 的 里 程 碑 ， 名 为 
mytag2 。 


下 面 的 命令 使 用 了 -m<msg> 参 数 ， 在 命令 行 给 出 了 新 建 里 程 碑 的 说 


明 。 





$ git tag -m "My first annotated tag." mytag2 





(3) 查看 里 程 碑 ， 可 以 看 到 该 里 程 碑 已 经 创建 。 





$ git tag -1 my* -ni 
mytag blank commit. 
mytag2 My first annotated tag. 





下 面 来 看 看 带 说 明 里 程 碑 的 奥秘 。 当 创建 了 带 说 明 的 里 程 碑 mytag2 
后 ， 会 在 版 本 库 的 .git/refs/tags 目 录 下 创建 一 个 新 的 引用 文件 。 


` 查看 一 下 这 个 引用 文件 的 内 容 : 





$ cat .git/refs/tags/mytag2 
149b6344e80fc1i90bda5621cd71df391d3dd465e 





" 用 git cat-file 命 令 检 查 该 里 程 碑 ( 带 说 明 的 里 程 碑 ) 指向 的 对 象 ， 


会 发 现 指 向 的 不 再 是 一 个 提交 ， 而 是 一 个 tag 对 象 。 





$ git cat-file -t mytag2 
tag 





. 查看 该 提交 的 内 容 ， 会 发 现 mytag2 对 象 的 内 容 不 是 之 前 我 们 熟悉 
的 提交 对 象 的 内 容 ， 而 是 包含 了 创建 里 程 碑 时 的 说 明 ， 以 及 对 应 的 提交 


ID 等 信息 。 





$ git cat-file -p mytag2 

object 8a9f3d1i6ce2b4d39b5d694de10311207f289153f 

type commit 

tag mytag2 

tagger user1 <user1i@sun.ossxp.com> Sun Jan 2 14:10:07 2011 +0800 
My first annotated tag. 





由 此 可 见 使 用 带 说 明 的 里 程 碑 ， 会 在 版 本 库 中 建立 一 个 新 的 对 象 
(tag 对 象 ) ， 这 个 对 象 会 记录 创建 里 程 碑 的 用 户 (tagger) ， 创 建 里 程 
碑 的 时 间 ， 以 及 为 什么 要 创建 里 程 碑 。 这 就 避免 了 轻 量 级 里 程 碑 因为 匿 
名 创建 而 无 法 追踪 的 缺点 。 


带 说 明 的 里 程 碑 是 一 个 tag 对 象 ， 在 版 本 库 中 以 一 个 对 象 的 方式 存 
在 ， 并 用 一 个 40 位 的 SHA1 哈 希 值 来 表示 。 这 个 哈 希 值 的 生成 方法 和 前 
面 介绍 的 commit 对 象 、tree 对 象 、blob 对 象 一 样 。 至 此 ，Git 对 象 库 的 四 
类 对 和 象 我 们 就 都 已 经 研究 到 了 。 





$ git cat-file tag mytag2 | wc -c 


$ (printf "tag 148\000"; git cat-file tag mytag2) | shalsum 
149b6344e80fc1i90bda5621cd71df391d3dd465e - 





里 然 mytag2 本 里 是 一 个 tag 对 象 ， 但 在 很 多 Git 命 令 中 ， 可 以 直接 将 


其 视 为 一 个 提交 。 下 面 的 git log 命 令 ， 显 示 mytag2 指 向 的 提交 日 志 。 





$ git log -1 --pretty=oneline mytag2 
8a9f3d16ce2b4d39b5d694de10311207f289153f blank commit for annotated tag test. 





有 了 时， 需要 得 到 里 程 碑 指 疝 的 提交 对 象 的 SHA1 哈 希 值 。 


" 直接 用 git fev-patse 命 令 查看 mytag2 得 到 的 是 tag 对 象 的 ID， 并 非 提 


交 对 象 的 ID。 





$ git rev-parse mytag2 
149b6344e8ofc190bda5621cd71df391d3dd465e 





` 使 用 下 面 几 种 不 同 的 表示 法 ， 则 可 以 获得 mytag2 对 象 所 指向 的 提 


交 对 象 的 ID。 





$ git rev-parse mytag2^{commit} 
8a9f3d16ce2b4d39b5d694de10311207f289153f 
$ git rev-parse mytag2^{} 
8a9f3d16ce2b4d39b5d694de10311207f289153f 
$ git rev-parse mytag2^0 
8a9f3d16ce2b4d39b5d694de10311207f289153f 
$ git rev-parse mytag2~0 
8a9f3d16ce2b4d39b5d694de10311207f289153f 








17.2.3” 带 签名 的 里 程 碑 


带 签 名 的 里 程 碑 和 上 面 介绍 的 带 说 明 的 里 程 碑 本 质 上 是 一 样 的 ， 都 
古 在 创建 里 程 碑 的 时 候 在 Git 对 象 库 中 生成 一 个 tag 对 象 ， 只 不 过 带 签名 
的 里 程 碑 多 做 了 一 个 工作 : 为 里 程 碑 对 象 添 加 GnuPG 签 名 。 








创建 带 签名 的 里 程 碑 也 非常 简单 ， 使 用 参数 -s 或 -u<key-id> 即 可 。 
还 可 以 使 用 -m<msg> 参 数 直接 在 命令 行 中 提供 里 程 碑 的 描述 。 创 建 带 答 
名 的 里 程 碑 的 一 个 前 提 是 需要 安装 GnupG， 并 且 建立 相应 的 公 钥 / 私 铀 
对 。 





GnuPG 可 以 在 各 个 平台 上 安装 。 


“ 在 Linux 如 Debian/Ubuntu 上 安装 ， 执 行 : 





$ sudo aptitude install gnupg 





. 在 Mac OS 又 上 可 以 通过 Homebrew 安 装 





$ brew install gnupg 





人 > es 


` 在 Windows 上 可 以 通过 cygwin 安 装 gnupg。 


为 了 演示 创建 带 签名 的 里 程 碑 ， 还 是 事先 创建 一 个 空 提交 : 





$ git commit --allow-empty -m "blank commit for GnuPG-signed tag test." 
[master ebcf6d6] blank commit for GnuPG-signed tag test. 





直接 在 刚刚 创建 的 空 提交 上 创建 一 个 市 签名 的 里 程 碑 mytag3 很 可 能 
会 失败 : 





$ git tag -s -m "My first GPG-signed tag." mytag3 
gpg: "user1 <user1@sun.ossxp.com>" 已 跳 过 : 私 钥 不 可 用 
gpg: signing failed: 私 钥 不 可 用 

error: gpg failed to Sign the tag 

error: unable to sign the tag 








之 所 以 签名 失败 ， 是 因为 找 不 到 签名 可 用 的 公 钥 / 私 钥 对 。 使 用 下 
面 的 命令 可 以 伍 看 当前 可 用 的 GnuPG 公 钥 。 





$ gpg --list-keys 


/home/jiangxin/ .gnupg/pubring.gpg 

pub ”14024D/FBC49D01 2006-12-21 [有 效 至 : 2016-12-18] 

uid Jiang Xin <worldhello.net@gmail.com> 
uid Jiang Xin <jiangxin@ossxp.com> 

sub ”2048g/448713EB 2006-12-21 [有 效 至 : 2016-12-18] 





可 以 看 到 GnuPG 的 公 钥 链 (pubring) 中 只 包含 了 Jiang Xin 用 户 的 公 
钥 ， 尚 没有 uesr1 用 户 的 公 钥 。 


实际 上 在 创建 带 签名 的 里 程 碑 时 ， 并 非 一 定 要 使 用 签名 者 本 人 的 公 
钥 / 私 钥 对 进行 签名 ， 使 用 -u<key-id> 参 数 调 用 就 可 以 用 指定 的 公 钥 / 私 铀 
对 进行 签名 ， 对 于 此 例 可 以 使 用 FBC49D01 作 为 <key-id>。 但 如 果 没 有 
可 用 的 公 钥 / 私 钥 对 ， 或 者 希望 使 用 提交 者 本 人 的 公 钥 / 私 钥 对 进行 签 
名 ， 就 需要 为 提交 者 : userl<userl1@sun.ossxp.com> 创 建 对 应 的 公 钥 / 私 
钥 对 。 


使 用 命令 gpg--gen-key 来 创建 公 钥 / 私 钥 对 。 





$ gpg --gen-key 








按照 提示 一 步 一 步 操 作 即 可 。 需 要 注意 的 有 : 


- 在 创建 公 钥 / 私 钥 对 时 ， 会 提示 输入 用 户 名 ， 输 入 Userf1， 提 示 输 
入 邮件 地 址 ， 输 入 usef1(Dsun.ossxp.com， 其 他 可 以 采用 默认 值 。 


.在 提示 输入 窗 码 时 ， 为 了 简单 起 见 可 以 直接 按 下 回 车 ， 即 使 用 空 


口令 。 


“ 在 生成 公 钥 / 私 钥 对 过 程 中 ， 会 提示 用 户 做 一 些 随机 操作 以 便 产 
生 更 好 的 随机 数 ， 这 时 不 停 的 晃动 鼠标 就 可 以 了 。 


创建 完毕 ， 再 碍 看 一 下 公 钼 链 。 





$ gpg --list-keys 

/home/jiangxin/ .gnupg/pubring.gpg 

pub ”14024D/FBC49D01 2006-12-21 [有 效 至 : 2016-12-18] 

uid Jiang Xin <worldhello.net@gmail.com> 
uid Jiang Xin <jiangxin@ossxp.com> 

sub ”2048g/448713EB 2006-12-21 [有 效 至 : 2016-12-18] 

pub 2048R/37379C67 2011-01-02 

uid User1 <useri@sun.ossxp.com> 

sub 2048R/2FCFB3E2 2011-01-02 





很 显然 用 户 user1 的 公 钥 / 私 钥 对 已 经 建立 。 现 在 就 可 以 直接 使 用 -s 参 
数 来 创建 带 签 名 的 里 程 碑 了 。 





$ git tag -s -m "My first GPG-signed tag." mytag3 





查看 里 程 碑 ， 可 以 看 到 该 里 程 碑 已 经 创建 。 





$ git tag -1 my* -ni 


mytag blank commit. 
mytag2 My first annotated tag. 
mytag3 My first GPG-signed tag. 








和 带 说 明 的 里 程 碑 一 样 ， 在 Git 对 象 库 中 也 建立 了 一 个 tag 对 象 。 碍 
看 该 tag 对 象 可 以 看 到 其 中 包含 了 GnuPG 签 名 。 





$ git cat-file tag mytag3 

object ebcf6d6b06545331df156687ca2940800a3c599d 
type commit 

tag mytag3 


tagger user1 <user1iQ@sun.ossxp.com> 1293960936 +0800 

My first GPG-signed tag. 

----- BEGIN PGP SIGNATURE----- 

Version: GnuPG v1.4.10 (GNU/Linux) 
iQEcCBAABAgAGBQJNIEboAAoOJEO9SW1fg3N5xn42gH/jFDEKobqlupNKFvmkI14t9d6 
J]JApDFUdcFMPWVvxo/eq8VjcQyRcb1iX1bGJj+pxXk455fDL1iNWonaJa6HE6RLU868x 
CQIWqwWelkCelfmO5GE9FnPd2SmJsiDkTPZZzINyaiHylF5ZbrExH506JyCFk//FC2 
8ZRApSbrsj3yAwMStwofGqHKLuYdq+sdepzGnnFnhhzkJhusMHUKTIfpLwaprhMsm 
1IIxKNm9i0Zf/tzq4a/RON8NiFH1/9M95iV200I9PUURWedVOtEPS60nax2yT3JE 
I/w9gtIBOeb5uAz2Xrt5AUwt9JJTkS5mmv2HBqWwCq5wefxs/ub26iPmef35PWwAgA= 
=jdrN 





要 验证 签名 的 有 效 性 ， 如 果 直 接 使 用 gpg 命 令 会 比较 及 烦 ， 因 为 需 
要 将 这 个 文件 拆 分 为 两 个 ， 一 个 是 不 包含 签名 的 里 程 碑 内 容 ， 为 外 一 个 
是 签名 本 身 。 还 好 可 以 使 用 命令 git tag-v 来 验证 里 程 碑 签名 的 有 效 性 。 








$ git tag -v mytag3 

object ebcf6d6b06545331df156687ca2940800a3c599d 

type commit 

tag mytag3 

tagger user1 <user1i@sun.ossxp.com> 1293960936 +0800 

My first GPG-signed tag. 

gpg: 于 2011 年 01 月 02 日 星期 日 17 时 35 分 36 秒 CST 创建 的 签名 ， 使 用 RSA， 钥 匙 号 37379C67 
























































ee | 


17.3 删除 里 程 厂 


如 果 里 程 碑 建立 在 了 错误 的 提交 上 ， 或 者 对 里 程 碑 的 命名 不 满意 ， 
可 以 删除 里 程 碑 。 删 除 里 程 碑 使 用 命令 git tag-d， 下 面 用 命令 删除 里 程 


碑 mytag。 


De ed to ya tas odatahy 
里 程 碑 没 有 类 似 reflog 的 变更 记录 机 制 ， 一 旦 删除 不 易 恢复 ， 慎 
用 。 在 删除 里 程 碑 mytag 的 命令 输出 中 ， 会 显示 该 里 程 碑 所 对 应 的 提交 
ID， 一 旦 发 现 删 除 错 误 ， 赶 紧 补 救 还 来 得 及 。 下 面 的 命令 实现 对 里 程 碑 
mytag 的 重建 。 





$ git tag mytag 60a2f4f 





Git 没 有 提供 对 里 程 碑 重 命名 的 命令 ， 如 果 对 里 程 碑 名 字 不 满意 的 
话 ， 可 以 删除 旧 的 里 程 碑 ， 然后 重新 用 新 的 名 称 创建 里 程 碑 。 


为 什么 没有 提供 重 命 名 里 程 碑 的 命令 呢 ? 按 理 说 只 要 
将 .git/refs/tags/ 下 的 引用 文件 改名 就 可 以 了 。 这 是 因为 里 程 碑 的 名 字 不 
但 反映 在 .gitrefs/tags 引 用 目录 下 的 文件 名 ， 而 且 对 于 市 说 明 或 签名 的 里 
程 碑 ， 里 程 碑 的 名 字 还 反映 在 tag 对 象 的 内 容 中 。 尤 其 是 市 签名 的 里 程 





碑 ， 如 果 修 改 里 程 碑 的 名 字 ， 不 但 里 程 碑 对 象 内 容 势 必要 变化 ， 而 且 里 
程 碑 也 要 重新 进行 签名 ， 这 显然 难以 自动 实现 。 





在 第 6 篇 第 35 章 的 “35.4 Git 版 本 库 整 理 ” 一 节 中 会 介绍 使 用 git filter- 
branch 命 令 实现 对 里 程 碑 目 动 重 命名 的 方法 ， 但 是 那个 方法 也 不 能 坚 发 
无 损 地 实现 对 签名 里 程 碑 的 重 命名 ， 被 重 命名 的 签名 里 程 碑 中 的 签名 会 
被 去 除 ， 从 而 成 为 带 说 明 的 里 程 碑 。 








17.4 不 要 随意 更 改 里 程 碑 





里 程 碑 建 立 后 ， 如 果 需 要 修改 ， 可 以 使 用 同样 的 里 程 碑 名 称 重 新 建 
并 ， 不 过 需要 加 上 -f 或 --force 参 数 强 制 履 新 已 有 的 里 程 碑 。 








更 改 里 程 碑 要 慎重 ,一 个 原因 是 里 程 碑 从 概念 上 讲 是 对 历史 提交 的 
一 个 标记 ， 不 应 该 随意 变动 。 男 外 一 个 原因 古里 程 碑 一 旦 被 他 人 同步 ， 
如 果 修 改 里 程 碑 ， 已 经 同步 该 里 程 碑 的 用 户 并 不 会 自动 更 新 ， 这 就 导致 
一 个 相同 名 称 的 里 程 碑 在 不 同 用 户 的 版 本 库 中 的 指向 不 同 。 下 面 束 看 看 
如 何 与 他 人 共享 里 程 碑 。 








现在 看 看 用 户 userl 的 工作 区 状态 。 可 以 看 出 现在 的 工作 区 相 比 上 游 
有 三 个 新 的 提交 。 





$ git status 

# On branch master 

# Your branch is ahead of 'origin/master' by 3 commits. 
# 

nothing to commit (working directory clean) 





那么 如 果 执 行 git push 命 令 问 上 游 推送 ， 会 将 本 地 创建 的 三 个 里 程 碑 
推送 到 上 游 吗 ? 通过 下 面 的 操作 来 试 一 试 。 


` 向 上 游 推送 。 





$ git push 

Counting objects: 3, done. 

Delta compression using up to 2 threads. 

Compressing objects: 100% (3/3), done. 

Writing objects: 100% (3/3), 512 bytes, done. 

Total 3 (delta 0), reused 0 (delta 0) 

Unpacking objects: 100% (3/3), done. 

To file:///path/to/repos/hello-world.git 
3e6070e..ebcf6d6 master -> master 





` 通过 执行 git ls-femote 可 以 查看 上 游 版 本 库 的 引用 ， 会 发 现 本 地 建 
立 的 三 个 里 程 碑 ， 并 没有 推送 到 上 游 。 





$ git ls-remote origin my* 








创建 的 里 程 碑 ， 默 认 只 在 本 地 版 本 库 中 可 见 ， 不 会 因为 对 分 文 执行 
推送 而 将 里 程 碑 也 推送 到 远程 版 本 库 。 这 样 的 设计 显然 更 为 合理 ， 人 否则 
的 话 ， 每 个 用 户 本 地 创建 的 里 程 碑 都 目 动 加 上 游 推 送 ， 那 么 上 游 的 里 程 
碑 将 有 多 么 杂乱 ， 而 且 不 同 用 户 创 建 的 相同 名 称 的 里 程 碑 会 互相 窗 盖 。 


1. 显 式 推送 以 共 至 里 程 碑 


如 果 用 户 确实 需要 将 某 些 本 地 建立 的 里 程 碑 推送 到 远程 版 本 库 ， 需 
要 在 git push 命 令 中 明确 地 表示 出 来 。 下 面 在 用 户 user1 的 工作 区 执行 命 
令 ， 将 mytag 里 程 碑 共享 到 上 游 版 本 库 。 





$ git push origin mytag 

Total 0 (delta 0), reused 0 (delta 0) 

To file:///path/to/repos/hello-world.git 
* [new tag] mytag -> mytag 





如 果 需 要 将 本 地 建立 的 所 有 里 程 碑 全 部 推送 到 远程 版 本 库 ， 可 以 使 
用 通配符 。 





$ git push origin refs/tags/* 
Counting objects: 2, done. 
Delta compression using up to 2 threads. 
Compressing objects: 100% (2/2), done. 
Writing objects: 100% (2/2), 687 bytes, done. 
Total 2 (delta 0), reused 0 (delta 0) 
Unpacking objects: 100% (2/2), done. 
To file:///path/to/repos/hello-world.git 

* [new tag] mytag2 -> mytag2 

* [new tag] mytag3 -> mytag3 





再 用 命令 git ls-remote 查 看 上 游 版 本 库 的 引用 ， 会 发 现 本 地 建立 的 三 
个 里 程 碑 ， 己 经 能 够 在 上 游 中 看 到 了 。 


LE | 


$ git ls-remote origin my* 


60a2f4f31e5dddd777c6ad37388fe6e5520734cb refs/tags/mytag 
149b6344e80fc1i90bda5621cd71df391d3dd465e refs/tags/mytag2 
8a9f3d1i6ce2b4d39b5d694de10311207f289153f refs/tags/mytag2^{} 
5dc2fc52f2dcb84987f511481cc6b71ec1b381f7 refs/tags/mytag3 
ebcf6d6b06545331df156687ca2940800a3c599d refs/tags/mytag3^{} 





2. 用 户 从 版 本 库 执 行 拉 回 操作 ， 会 目 动 获取 里 程 碑 么 ? 


用 户 user2 的 工作 区 中 如 果 执 行 git fetch 或 git pull 操 作 ， 能 自动 将 用 
户 userl 推 送 到 共享 版 本 库 中 的 里 程 碑 获取 到 本 地 版 本 库 么 ?下 面 实践 一 
下 


(1) 进入 user2 的 工作 区 。 





$ cd /path/to/user2/workspace/hello-world/ 





(2) 执行 git pull 命 令 ， 从 上 游 版 本 库 获 取 提 交 。 





$ git pull 

remote: Counting objects: 5, done. 

remote: Compressing objects: 100% (5/5), done. 
remote: Total 5 (delta 0), reused 0 (delta 0) 
Unpacking objects: 100% (5/5), done. 

From file:///path/to/repos/hello-world 


3e6070e..ebcf6d6 master -> origin/master 
* [new tag] mytag3 -> mytag3 
From file:///path/to/repos/hello-world 
* [new tag] mytag -> mytag 
* [new tag] mytag2 -> mytag2 


Updating 3e6070e. .ebcf6d6 
Fast-forward 





(3) 可 见 执行 git pull 操 作 ， 能 够 在 获取 远程 共 圣 版 本 库 的 提交 的 
同时 ， 获 取 新 的 里 程 碑 。 下 面 的 命令 可 以 看 到 本 地 版 本 库 中 的 里 程 碑 。 





$ git tag -ni -1 my* 


mytag blank commit. 
mytag2 My first annotated tag. 
mytag3 My first GPG-signed tag. 





3. 里 程 碑 变更 能 够 自动 同步 吗 ? 


里 程 碑 可 以 被 强制 更 新 。 当 里 程 碑 被 改变 后 ， 己 经 获取 到 里 程 碑 的 
版 本 库 再 次 使 用 获取 或 拉 回 操作 ， 能 够 自动 更 新 里 程 碑 吗 ? 答案 是 不 
能 。 可 以 看 看 下 面 的 操作 。 


(1) 用 户 user2 强 制 更 新 里 程 碑 mytag2。 





$ git tag -f -m "user2 update this annotated tag." mytag2 HEADA^ 
Updated tag 'mytag2' (was 149b634) 





(2) 里 程 碑 mytag2 已 经 是 不 同 的 对 象 了 。 





$ git rev-parse mytag2 

Qe6c780ffofe06635394db9dac6fb494833df8df 

$ git cat-file -p mytag2 

object 8a9f3d1i6ce2b4d39b5d694de10311207f289153f 

type commit 

tag mytag2 

tagger user2 <user2@moon.ossxp.com> Mon Jan 3 01:14:18 2011 +0800 
user2 update this annotated tag. 





(3) 为 了 更 改 远程 共 胖 服务 器 中 的 里 程 碑 ， 同 样 需 要 显 式 推送 。 
即 在 推送 时 写 上 要 推送 的 里 程 碑 名 称 。 





$ git push origin mytag2 

Counting objects: 1, done. 

Writing objects: 100% (1/1), 171 bytes, done. 
Total 1 (delta 0), reused 0 (delta 0) 
Unpacking objects: 100% (1/1), done. 

To file:///path/to/repos/hello-world.git 


149b634. .0e6c780 mytag2 -> mytag2 





(4) 切换 到 另外 一 个 用 户 userl 的 工作 区 。 





$ cd /path/to/user1i/workspace/hello-world/ 





(5) 用 户 user1l 执 行 拉 回 操作 ， 没 有 获取 到 新 的 里 程 碑 。 





$ git pull 
Already up-to-date. 





(6) 用 户 user1 必 须 显 式 地 执行 拉 回 操作 。 即 要 在 git pull 的 参数 中 
使 用 引用 表达 式 。 








所 谓 引 用 表达 式 就 是 用 冒号 分 隅 的 引用 名 称 或 通配符 。 用 在 这 里 代 
表 用 远程 共享 版 本 库 的 引用 refs/tag/mytag2 履 盖 本 地 版 本 库 的 同名 引 
用 。 





$ git pull origin refs/tags/mytag2:refs/tags/mytag2 
remote: Counting objects: 1, done. 
remote: Total 1 (delta 0), reused 0 (delta 0) 
Unpacking objects: 100% (1/1), done. 
From file:///path/to/repos/hello-world 

- [tag update] mytag2 -> mytag2 
Already up-to-date. 





关于 里 程 碑 的 共享 和 同步 操作 ， 看 似 很 烦琐 ， 但 用 心 体会 融会 感觉 
到 Git 关 于 里 程 碑 共 至 的 设计 是 非常 合理 和 人 性 化 的 : 


" 里 程 碑 共 享 ， 必 须 显 式 的 推送 。 即 在 推送 命令 的 参数 中 ， 标 明 要 


推送 哪个 里 程 碑 。 





显 式 推送 是 防止 用 户 随意 推送 里 程 碑 导 人 致 共享 版 本 库 中 里 程 碑 沁 小 
的 方法 。 当 然 还 可 以 参考 第 5 篇 “第 30 章 Gitolite 服 务 架设 ”的 相关 章节 为 
共 胖 版 本 库 谎 加 授权 ， 只 人 允许 部 分 用 户 癌 服务 器 推送 里 程 碑 。 


. 执行 获取 或 拉 回 操作 ， 自 动 从 远程 版 本 库 获取 新 里 程 碑 1， 并 在 本 
地 版 本 库 中 创建 。 
获取 或 拉 回 操作 ， 只 会 将 获取 的 远程 分 支 所 包含 的 新 里 程 碑 同 步 到 


本 地 ， 而 不 会 将 远程 版 本 库 的 其 他 分 文中 的 里 程 碑 获取 到 本 地 。 这 既 方 
便 了 里 程 碑 的 取得 ， 又 防止 本 地 里 程 碑 因 同 步 远程 版 本 库 而 泛滥 。 








. 如 果 本 地 已 有 同名 的 里 程 碑 ， 默认 不 会 从 上 游 同 步 里 程 碑 ， 即 使 
两 者 里 程 碑 的 指向 是 不 同 的 。 理 解 这 一 点 非常 重要 。 这 也 就 要 求 里 程 碑 
一 旦 共享 ， 就 不 要 再 修改 。 


17.6 ”删除 远程 版 本 库 的 里 程 碑 


假如 癌 远 程 版 本 库 推 送 里 程 碑 后 ， 忽 然 发 现 里 程 碑 创建 在 了 错误 的 
提交 上 ， 为 了 防止 其 他 人 获取 到 错误 的 里 程 碑 ， 应 该 尽快 将 里 程 碑 删 


除 。 


删除 本 地 里 程 碑 非常 简单 ， 使 用 git tag-d<tagname> 就 可 以 了 ， 但 是 
如 何 撤销 已 经 推送 到 远程 版 本 库 的 里 程 碑 呢 ? 需要 登录 到 服务 器 上 吗 ? 
或 者 需要 麻烦 管理 员 吗 ? 不 必 ! 可 以 直接 在 本 地 版 本 库 执行 命令 删除 远 
程 版 本 库 中 的 里 程 碑 。 





使 用 git push 命 令 可 以 删除 远程 版 本 库 中 的 里 程 碑 。 用 法 如 下 : 


命令 :git push <remote_url> :<tagname> 


该 命令 的 最 后 一 个 参数 实际 上 是 一 个 引用 表达 式 ， 引 用 表达 式 一 般 
的 格式 为 <ref>:<ref>。 该 推送 命令 使 用 的 引用 表达 式 冒 写 前 的 引用 被 省 
略 ， 其 含义 是 将 一 个 空 值 推送 到 远程 版 本 库 对 应 的 引用 中 ， 亦 即 删 除 远 
程 版 本 库 中 相关 的 引用 。 这 个 命令 不 但 可 以 用 于 删除 里 程 碑 ， 在 下 一 草 
还 可 以 用 它 删 除 远程 版 本 库 中 的 分 文 。 


下 面 演示 在 用 户 userl 的 工作 区 执行 下 面 的 命令 删除 远程 共 孚 版 本 库 
中 的 里 程 碑 mytag2。 


(1) 切换 到 用 户 userl 工 作 区 。 





$ cd /path/to/user1i/workspace/hello-world 





(2) 执行 推送 操作 删除 远程 共 至 版 本 库 中 的 里 程 碑 。 





$ git push origin :mytag2 
To file:///path/to/repos/hello-world.git 
- [deleted] mytag2 





(3) 碍 看 远程 共 孚 库 中 的 里 程 碑 ， 发 现 mytag2 的 确 已 经 被 删除 。 





$ git ls-remote origin my* 

60a2f4f31e5dddd777c6ad37388fe6e5520734cb refs/tags/mytag 
5dc2fc52f2dcb84987f511481cc6b71ec1b381f7 refs/tags/mytag3 
ebcf6d6b06545331df156687ca2940800a3c599d refs/tags/mytag3^{} 





17.7 里 程 碑 命名 规范 





在 正式 项 目的 版 本 库 管 理 中 ， 要 为 里 程 碑 创建 计 廊 一 些 规则 ， 庄 


如 : 
. 对 创建 里 程 碑 进行 权限 控制 ， 参 考 后 面 Git 服 务 受 的 相关 章 
yg 


` 不 要 使 用 轻 量 级 里 程 碑 〈 只 用 于 本 地 临时 性 里 程 碑 ) ， 而 是 要 使 
用 带 说 明 的 里 程 碑 ， 其 至 要 求 必须 使 用 带 签名 的 里 程 碑 。 


` 如 果 使 用 带 签名 的 里 程 碑 ， 可 以 考虑 设置 专用 账户 ， 使 用 专用 的 
私 钥 创建 签名 。 


.里程碑 的 命名 要 使 用 统一 的 风格 ， 并 很 容易 和 最 终 产 品 显 示 的 版 
本 号 相对 应 。 





Git 的 里 程 碑 命 名 还 有 一 些 特殊 的 约定 需要 遵守 。 实 际 上 ， 下 面 的 
这 些 约定 对 于 下 一 章 要 介绍 的 分 文 及 任何 其 他 引用 均 适 用 : 





. 不 要 以 符号 “-” 开 头 。 以 免 在 命令 行 中 被 当成 命令 的 选项 。 


. 可 以 包含 路 径 分 隔 符 “/”， 但 是 路 径 分 隔 符 不 能 位 于 最 后 。 


使 用 路 径 分 隔 符 创建 tag 实 际 上 会 在 引用 目录 下 创建 子 目 录 。 例 如 
名 为 demo/v1.2.1 的 里 程 碑 ， 就 会 创建 目录 .gitrefs/tags/demo 并 在 该 目录 
下 创建 引用 文件 v1.2.1。 


- 不 能 出 现 两 个 连续 的 点 “..”。 因 为 两 个 连续 的 点 被 用 于 表示 版 
本 范围 ， 当 然 更 不 能 使 用 三 个 连续 的 点 。 


" 如 果 在 里 程 碑 命名 中 使 用 了 路 径 分 隔 符 “/”， 就 不 能 在 任何 一 
个 分 隔 路 径 中 以 点 “.” 开 头 。 这 是 因为 里 程 碑 在 用 简写 格式 表达 时 ， 
可 能 造成 以 一 个 点 “.” 开 头 。 这 样 的 引用 名 称 在 用 作 版 本 范围 的 最 后 
一 个 版 本 时 ， 本 来 两 点 操作 符 变 成 了 三 点 操作 符 ， 从 而 造成 歧义 。 


` 不 能 在 里 程 碑 名 称 的 最 后 出 现 点 “. 。 和 否则 作为 第 一 个 参数 出 
现在 表示 版 本 范围 的 表达 式 中 时 ， 本 来 版 本 范围 表达 式 可 能 用 的 是 两 点 


操作 符 ， 结 果 被 误 作 三 点 操作 符 。 


. 不 能 使 用 特殊 字符 ， 如 : 空格 、 疲 浪 线 “~”、 脱 字符 “^”、 置 
号 4 . 问号 “? » 星 号 《水 尹 方 括号 加 罗 ， 以 及 字符 \177 (删除 


字符 ) 或 小 于 \040 (32) 的 Ascii 码 都 不 能 使 用 。 


这 是 因为 波浪 线 “~” 和 脱 字 符 W* 都 用 于 表示 一 个 提交 的 祖先 提交。 
冒号 被 用 作 引 用 表达 式 来 分 隔 两 个 不 同 的 引用 ， 或 者 用 于 分 隔 引 用 代表 
的 树 对 象 和 该 目录 树 中 的 文件 。 问 号 、 星 号 和 方 括号 在 引用 表达 式 中 都 
被 用 作 通 配 符 。 








. 不 能 以 “ .lock 为 结尾 。 因 为 以 “ .lock ”结尾 的 文件 是 里 程 碑 操 
作 过 程 中 的 临时 文件 。 


不 能 包含 “@{” 字 事 。 和 否则 易 和 reflog 的 “@ 人 ”语法 相 混 消 。 


不 能 包含 反 作 线 “\”。 因 为 反 针线 用 于 命令 行 或 shell 脚 木 会 造 


Git 还 专门 为 检查 引用 名 称 是 否 符合 规范 提供 了 一 个 命令 : git 
check-ref-format。 知 该 命令 返回 值 为 0， 则 引用 名 称 符 合 规范 ， 藻 返回 
值 为 1， 则 不 符合 规范 。 





























git check-ref-format refs/tags/.name || echo "返回 $?， 不 合法 的 引用 " 
可 1， 不 合法 的 引用 























$ 
返 




















1.Linux 中 的 里 程 碑 





Linux 内 核 项 目 无 疑 是 使 用 Git 版 本 库 时 间 最 久远 ， 也 古 最 重量 级 的 
项 目 。 研 究 Linux 内 核 项 目 本 身 的 里 程 碑 命名 和 管理 ， 无 疑 会 为 目 己 的 


项 目 提 供 借鉴。 








(1) 首先 看 看 Linux 中 的 里 程 碑 命名 。 可 以 看 到 里 程 碑 都 是 以 字母 
V 开 头 。 





$ git ls-remote --tags \ 
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6-stable.git \ 
V2.6.36* 

25427f38d3b791d986812cb81c68df38e8249ef8 refs/tags/v2.6.36 


fe6f94e2ab1b33f0082ac22d71f66385a60d8157f refs/tags/v2.6.36^{} 


8ed88d401f908a594cd74a4f2513bofabd32b699 refs/tagSs/v2.6.36-rc1l 
da5cabf80e2433131bfoed8993abcgof7ea618c73 refs/tags/v2.6.36-rc1i^{} 
7619e63f48822b2c68d0e108677340573873fb93 refs/tags/v2.6.36-rc8 
cd07202cc8262e1669edff0d97715f3dd9260917 refs/tags/v2.6.36-rc8^{} 
9d389cb6dcae347cfcdadf2aiec5e66fc7a667ea refs/tags/v2.6.36.1 
bf6ef02e53e18dd14798537e530e00b80435ee86 refs/tags/v2.6.36.1^{} 
ee7b38c91f3d718ea4035a331c24a56553e90960 refs/tags/v2.6.36.2 
al1346c99fc89f2b3d35c7d7e2e4aef8ea4124342 refs/tags/v2.6.36.2^{} 








(2) 以 -rc<num> 为 后 缀 的 是 先 于 正式 版 发 布 的 预 肥 布 版 本 。 


可 以 看 出 这 个 里 程 碑 是 一 个 带 签 名 的 里 程 碑 。 关 于 此 里 程 碑 的 说 明 
也 是 再 简练 不 过 了 。 





$ git Show v2.6.36-rc1 

tag v2.6.36-rc1 
Tagger: Linus Torvalds <torvalds@linux-foundation.org> 
Date: Sun Aug 15 17:42:10 2010 -0700 

Linux 2.6.36-rci 

----- BEGIN PGP SIGNATURE----- 
Version: GnuPG v1.4.10 (GNU/Linux) 
iEYEABECAAYFAkxoiwgACgkQF3YsRNbiHLtYKQCfQSIVCcjJ2hvLj6IWgP9xK2FE7T 
bPoAniJ1CjbwLxQBudRi71FvubqPLuVC 

=iuls 

----- END PGP SIGNATURE----- 

commit da5cabf80e2433131bfoed8993abcgof7ea618c73 
Author: Linus Torvalds <torvalds@linux-foundation.org> 
Date: Sun Aug 15 17:41:37 2010 -0700 

Linux 2.6.36-rci 

diff --git a/Makefile b/Makefile 

index 788111d..f3bdff8 100644 

--- a/Makefile 

+++ b/Makefile 
QQ -1, 7 +1, 7 @@ 

VERSION = 2 

PATCHLEVEL = 6 

-SUBLEVEL = 35 

-EXTRAVERSION = 

+SUBLEVEL = 36 

+EXTRAVERSION = -rci 

NAME = Sheep on Meth 

# *DOCUMENTATION* 





(3) 正式 发 布 版 去 把 了 预 发 布 版 的 后 缀 。 





$ git show v2.6.36 

tag v2.6.36 

Tagger: Linus Torvalds <torvalds@]linux-foundation.org> 

Date: Wed Oct 20 13:31:18 2010 -0700 

Linux 2.6.36 

The latest and greatest, and totally bug-free. At least until] 2.6.37 
comes along and shoves it under a speeding train like some kind of a 
bully. 

----- BEGIN PGP SIGNATURE----- 
Version: GnuPG v1.4.10 (GNU/Linux) 
iEYEABECAAYFAky/UcwACgkQF3YsRnbiHLvg/ACffKjAb1ifD6fpqcHbSijHHpbP3 
4SkANR4xOy7iKhmfS50ZrVsOkFFTUBHG 

=JD3z 

----- END PGP SIGNATURE----- 

commit f6f94e2ab1ib33f0082ac22d71f66385a60d8157f 
Author: Linus Torvalds <torvalds@linux-foundation.org> 

Date: Wed Oct 20 13:30:22 2010 -0700 

Linux 2.6.36 

diff --git a/Makefile b/Makefile 

index 7583116. .860c26a 100644 

--- a/Makefile 

+++ b/Makefile 
@@ -1, 7 +1, 7 @@ 

VERSION = 2 

PATCHLEVEL = 6 

SUBLEVEL = 36 
-EXTRAVERSION 
+EXTRAVERSION 
NAME = Flesh-Eating Bats with Fangs 
# *DOCUMENTATION* 


-rc8 








(4) 正式 发 布 后 的 升级 /修正 版 本 是 通过 最 后 一 位 数字 的 变动 来 体 
现 的 。 





$ git show v2.6.36.1 
tag v2.6.36.1 
Tagger: Greg Kroah-Hartman <gregkh@suse.de> 
Date: Mon Nov 22 11:04:17 2010 -0800 
This is the 2.6.36.1 Stable release 
----- BEGIN PGP SIGNATURE----- 
Version: GnuPG v2.0.15 (GNU/Linux) 
iEYEABECAAYFAkzqvrIACgkQMUfUDdst+ym9VQCgmE1LK2eC/LE9SHkscsxL1X62P 
8FOANRI28EHENLXC+FBPt+AFWoT9f1N8 
=BX50 
----- END PGP SIGNATURE----- 
commit bf6ef02e53e18dd14798537e530e00b80435ee86 
Author: Greg Kroah-Hartman <gregkhQ@suse .de> 
Date: Mon Nov 22 11:03:49 2010 -0800 
Linux 2.6.36.1 
diff --git a/Makefile b/Makefile 
index 860c26a..dafd22a 100644 
--- a/Makefile 
+++ b/Makefile 
@@ -1, 7 +1, 7 @@ 


VERSION = 2 

PATCHLEVEL = 6 

SUBLEVEL = 36 

-EXTRAVERSION = 
+EXTRAVEKSEON = .1 

NAME = Flesh-Eating Bats with Fangs 
# *DOCUMENTATION* 





2.Android 项 目 





看 看 其 他 项 目的 里 程 碑 命名 ， 会 发 现 不 同 项 目 关 于 里 程 碑 的 命名 各 
不 相同 。 但 是 对 于 同一 个 项 目 要 在 里 程 碑 命名 上 遵照 同一 标准 ， 并 能 够 
和 软件 版 本 写 正确 地 对 应 。 








Android 项 目 是 一 个 非常 有 特色 的 使 用 Git 版 本 库 的 项 目 ， 在 后 面 会 
用 两 章 介 绍 Android 项 目 为 Git 带 来 的 两 个 新 工具 。 看 看 Android 项 目的 里 
程 碑 编号 对 自己 版 本 库 的 管理 有 无 启发 。 





(1) 看 看 Android 项 目 中 的 里 程 碑 命 名 ， 会 发 现 其 里 程 碑 的 命名 格 
式 为 android-< 大 版 本 号 > T< 小 版 本 号 >。 





$ git ls-remote --tags \ 
git://android.git.kernel.org/platform/manifest.git \ 
android-2.2* 


6a03ae8f564130cbb4a11acfc49bd705df7c8df6 refs/tags/android-2.2.1_r1 
599e242dea48f84e2f26054b0d1721e489043440 refs/tags/android-2.2.1_r1i^{} 
656ba6fdbd243153af6ec31017de38641060bf1e refs/tags/android-2.2_r1 
27cd0e346d1f3420c5747e01d2cb35e9ffd025ea refs/tags/android-2.2_r1i^{} 
feéb7c499be268f1613d8cd70f2a05c12e01bcb93 refs/tags/android-2.2_r1.1 
bd3e9923773006a0a5f782e1f21413034096c4b1 refs/tags/android-2.2_r1.1 人 ^{} 
03618e01ec9bddo6fd8fe9afdbdcbaf4b84092c5 refs/tags/android-2.2_r1.2 
ba7111e1d6fd26ab150bafa029fd5eab8196dad1 refs/tags/android-2.2_r1.2^{} 
e03485e978ce1662a1285837f37ed39eadaedb1d refs/tags/android-2.2_r1i.3 
7386d2d07956be6e4f49a7e83eafb12215e835d7 refs/tags/android-2.2_r1.3^{} 





(2) 里 程 碑 的 创建 过 程 中 使 用 了 专用 账号 和 GnuPG 签 名 。 


一 一 


$ git show android-2.2_r1 
tag android-2.2_r1 
Tagger: The Android Open Source Project <initial-contribution@android,.com> 
Date: Tue Jun 29 11:28:52 2010 -0700 
Android 2.2 release 1 
----- BEGIN PGP SIGNATURE----- 
Version: GnuPG v1.4.6 (GNU/Linux) 
ID8DBQBMKJjtm6K0/XgZzdqdxDngRA1LBUAJ9QwgFbUL592FgRZLTLLbzhKsSQ8ACffQu5 
Mjxg5X90c+7N1DfdU+pmOcI= 
=ONGO 
----- END PGP SIGNATURE----- 
commit 27cdoe346d1f3420c5747e01d2cb35e9ffd025ea 
Author: The Android Open Source Project <initial-contribution@android ,com> 
Date: Tue Jun 29 11:27:23 2010 -0700 
Manifest for android-2.2_r1 
diff --git a/default.xml b/default.xml 
index 4f21453..aaa26e3 100644 
--- a/default.xml 
+++ b/default.xml 
@@ -3, 7 +3, 7 @@ 
<remote name="korg" 
fetch="git://android.git.kernel.org/" 
review="review,.source.android.com" /> 
- <default revision="froyo" 
+ <default revision="refs/tags/android-2.2_r1" 
remote="korg" /> 


第 18 音 ”Git 分 支 





分 支 是 我 们 的 老 朋友 了 ， 第 6 章 、 第 7 章 和 第 8 章 就 已 经 从 实现 原理 
上 介绍 了 分 文 。 您 想必 已 经 知道 了 分 文 master 的 存在 方式 无 非 就 是 在 目 
录 .git/refs/heads 下 的 文件 (或 称 引 用 〉 而 已 。 也 看 到 了 分 文 master 的 指 
向 如 何 随 着 提交 而 变化 ， 如 何 通 过 git reset 命 令 而 重 置 ， 以 及 如 何 使 用 
git checkout 命 令 而 检 出 。 








之 前 的 章节 都 只 用 到 了 一 个 分 文 : master 分 文 ， 而 在 本 章 会 接触 到 
多 个 分 支 。 会 从 应 用 的 角度 上 介绍 分 支 的 几 种 不 同类 型 : 发 布 分 支 、 特 
性 分 支 和 卖主 分 文 。 在 本 章 可 以 学 习 到 如 何 对 多 分 支 进 行 操作 ， 如 何 创 
建 分 支 ， 如 何 切 换 到 其 他 分 支 ， 以 及 分 支 之 间 的 合并 、 变 基 等 。 





18.1 代码 管理 之 殊 


分 文 是 代码 管理 的 利 硕 。 如 果 疫 有 有 效 的 分 文 管 理 ， 代 码 管理 就 适 
应 不 了 复杂 的 开发 过 程 和 项 目的 需要 。 在 实际 的 项 目 实践 中 ， 单 一 分 文 
的 单线 开发 模式 远 远 不 够 ， 因 为 : 


` 成 功 的 软件 项 目 大 多 要 经 过 多 个 开发 周期 ， 发 布 多 个 软件 版 本 。 
每 个 已 经 发 布 的 版 本 都 可 能 发 现 Bug， 这 就 需要 对 历史 版 本 进行 更 改 。 


* 有 前 上 脆性 的 项 目 管理 ， 新 版 本 的 开发 往往 是 和 当前 版 本 同步 进行 
的 。 如 果 两 个 版 本 的 开发 都 混杂 在 mastet 分 支 中 ， 肯 定 会 是 一 场 灾难 。 


` 如 果 产 品 要 针对 不 同 的 客户 定制 ， 肯 定 是 希望 客户 越 多 越 好 。 如 
果 所 有 的 客户 定制 都 混杂 在 一 个 分 支 中 ， 必 定 会 带 来 混乱 。 如 果 使 用 多 
个 分 支管 理 不 同 的 定制 ， 但 若是 管理 不 善 ， 分 支 之 间 定 制 功 能 的 迁移 就 


会 成 为 头痛 的 问题 。 


小 


` 即便 是 所 有 成 员 都 在 为 同一 个 项 目的 同一 个 版 本 进行 工作 ， 每 个 
人 领受 任务 却 不 尽 相 同 ， 有 的 任务 开发 周期 会 很 长 ， 有 的 任务 需要 对 软 
件 架 构 进 行 较 大 的 修改 ， 如 果 所 有 人 都 工作 在 同一 分 支 中 ， 就 会 因为 过 
多 过 频 的 冲突 导致 效率 低下 。 


“ 敏捷 开发 (不 管 是 极限 编程 XP 还 是 Scrum 或 其 他 ) 是 最 有 效 的 项 


目 管理 模式 ， 其 最 有 效 的 一 个 实践 就 是 快速 和 迭代、 每 晚 编 译 。 如 果 不 能 
将 项 目的 各 个 功能 模块 的 开发 通过 分 支 进 行 隔离 ， 在 软件 集成 上 就 会 遭 
遇 困 难 。 


18.1.1 发布 分 支 


在 2006 年 我 接触 到 一 个 项 目 团队 ， 使 用 Subversion 做 版 本 控制 。 最 
为 困扰 项 目 经 理 的 是 刚刚 修正 产品 的 一 个 Bug， 马 上 又 会 接二连三 地 发 
现 新 的 Bug。 在 访谈 开发 人 员 ， 询 问 开 发 人 员 是 如 何 修正 Bug 的 时 候 ， 
开发 人 员 的 回答 让 我 大 吃 一 恢 :“ 当 发 现 产 品 出 现 Bug 的 时 候 ， 我 要 中 断 
当前 的 工作 ， 把 我 正在 开发 的 新 功能 的 代码 注释 控 ， 然 后 再 去 修改 
Bug， 修 改 好 就 生成 一 个 war 包 (Java 开 发 网 站 项 目 ) 给 运 维 部 门 ， 扔 到 
网 站 上 去 。” 





于 是 我 就 画 了 下 面 的 一 个 图 〈 图 18-1) ， 大 致 描述 了 这 个 团队 进行 
Bug 修 正 的 过 程 ， 从 中 可 以 很 容易 地 看 出 问题 的 端倪 。 这 个 图 对 于 Git 其 
至 其 他 版 本 库 控制 系统 同样 适用 。 





Fasd fix1 a hg fix2 


图 18-1 为 什么 Bug 没 完 没 了 


说 明 : 
` 图 18-1 中 的 图 示 中 ， 开 发 者 针对 功能 1 做 了 一 个 提交 ， 编 


号 “F1.1”。 这 时 客户 报告 已 发 布 的 产品 出 现 了 Bug。 


` 于 是 开发 者 匆忙 地 干 了 起 来 ， 图 示人 @O 显 示 了 该 开发 者 修正 Bug 的 
过 程 : 将 新 提交 的 针对 功能 1 的 代码 “F1.1 注释 挤 ， 然 后 提交 一 个 修正 


Bug 的 提交 (编号 : fix1) 。 


开发 者 编译 出 已 发 布 软件 的 修订 版 交 给 客户 ， 接 着 开始 功能 1 的 
开发 。 图 示人 @@) 显 示 了 开发 者 针对 功能 1 做 出 了 一 个 新 的 提交 “F1.2 。 


. 客户 再 次 在 已 发 布 版 本 中 发 现 一 个 Bug。 开 发 者 再 次 开始 Bug 修 正 
I 


` 图 示 罗 和 图 示 回 显示 了 此 工作 模式 下 非常 容易 在 修复 一 个 Bug 的 
时 候 引 入 新 的 Bug。 


` 图 示 图 的 问题 在 于 开发 者 注释 功能 1 的 代码 时 ， 不 小 心 
将 “fix1” 的 代码 也 注释 掉 了 ， 导 致 曾经 修复 的 Bug 在 已 发 布 软件 的 修订 
版 中 重 现 。 


“图 示 加 的 问题 在 于 开发 者 没有 将 功能 1 的 代码 别 出 干净 ， 导 致 在 
已 发 布 产 品 的 修订 版 本 中 引入 了 不 完整 和 不 需要 的 功能 代码 。 用 户 可 能 
看 到 一 个 新 的 但 是 不 能 使 用 的 菜单 项 ， 其 至 更 粮 。 


使 用 版 本 控制 系统 的 分 支 功能 ， 可 以 避免 对 已 发 布 的 软件 版 本 进行 
Bug 修 正 时 引入 新 功能 的 代码 ， 或 者 因 误 删 其 他 Bug 修 正 代 码 寻 致 己 修 
复 问 题 重 现 。 在 这 种 情况 下 创建 的 分 文 有 一 个 专 有 的 名 称 : Bugfix 分 文 
或 发 布 分 文 (Release Branch) 。 之 所 以 称 为 发 布 分 文 ， 是 因为 在 软件 
新 版 本 发 布 后 经 癌 使 用 此 技术 进行 软件 维护 ， 发 布 升级 版 本 。 





图 18-2 演 示 了 如 何 使 用 发 布 分 文 应 对 Bug 修 正 的 过 程 。 


0 a> 人 


FL。 
有 X1 
(2) 2006/10 ] > 
Fl1.1 
fixl 
(3) 2006/10 ] 下 
as fix]1 
fix1 
(4) 2006/10 Po) 
A 人 。 、 全 ) 
F1.1 fix] F1.2 
fixl fix2 
@) 2006/10 ] EE ) 
F1.1 fix] F1.2 fix2 


图 18-2 使 用 发 布 分 支 的 Bug 修 正 过 程 
说 明 : 


. 图 18-2 中 的 图 示 四 ， 可 以 看 到 开发 者 创建 了 一 个 发 布 分 支 
(Bugfix 分 支 ) ， 在 分 支 中 提交 修正 代码 “fix1”。 注 意 此 分 支 是 自 上 次 
软件 发 布 时 最 后 一 次 提交 进行 创建 的 ， 因 此 分 支 中 没有 包含 开发 者 为 新 


功能 所 做 的 提交 “F1.1”， 是 一 个 “干净 ”的 分 支 。 
. 图 示 @@ 可 以 看 出 从 发 布 分 支 向 主线 做 了 一 次 合并 ， 这 是 因为 在 主 
线 上 也 同样 存在 该 Bug， 需 要 在 主线 上 也 做 出 相应 的 更 改 。 


` 图 示 (4)， 开 发 者 继续 开发 ， 针 对 功能 1 执行 了 一 个 新 的 提交 ， 编 
号 “F1.2”。 这 时 ， 客 户 报告 有 新 的 Bug。 


` 继续 在 发 布 分 支 上 进行 Bug 修 正 ， 参 考 图 示 @。 当 修正 完成 〈 提 
交 “fix2”) 时 ， 基 于 发 布 分 支 创 建 一 个 新 的 软件 版 本 发 给 客户 。 不 要 
忘 了 向 主线 合并 ， 因 为 同样 的 Bug 可 能 在 主线 上 也 存在 。 


天 于 如 何 基 于 一 个 历史 提交 创建 分 文 ， 以 及 如 何在 分 文 之 间 进 行 合 
并 ， 在 本 章 后 面 的 内 容 中 会 详细 介绍 。 


18.1.2 ”特性 分 文 





有 这 么 一 个 软件 项 目 ， 项 目 己 经 延期 了 可 是 还 是 看 不 到 一 点 要 完成 
的 样子 。 最 终老 板 变 得 有 些 不 耐烦 了 ， 说 道 : “那么 就 砍 掉 一 些 功 能 
吧 ”。 项 目 经 理 听闻 一 阵 上 蚁 党 ， 因 为 项 目 经 理 知道 目 己 负责 的 这 个 项 目 

是 单一 主线 开发 ， 要 将 一 个 功能 从 中 撤销 ， 工 作 量 非常 大 ， 而 且 
还 可 能 会 牵涉 到 其 他 相关 模块 的 变更 。 

















图 18-3 就 是 这 个 项 目的 版 本 库 示意 图 ， 显 然 这 个 项 目的 代码 管理 没 


有 使 用 分 文 。 


DD ge 


F1,1 F2.1 F1,2 F2.2 
(2) 
“i 事 > 
EE F2.,1 F1.2 F2.2 F2,X 
3 —o——— A A060 
3 入 A 二 
FL. F2.1 Fl.2 F222 F2.X Fl1.3 Fl.4 


图 18-3 ”没有 使 用 分 支 导 致 项 目 拖延 
说 明 : 


. 图 18-3 中 的 图 示人 四 ， 用 圆圈 代表 功能 1 的 历次 提交 ， 用 三 角 代 替 功 
能 2 的 历次 提交 。 因 为 所 有 开发 者 都 在 主线 上 工作 ， 所 以 提交 混杂 在 一 
起 。 


. 当 老 板 决定 功能 2 不 在 这 一 版 本 的 产品 中 发 布 ， 延 期 到 下 一 个 版 
本 时 ， 功 能 2 的 开发 者 做 了 一 个 (或 者 若干 个 ) 反 向 提交 ， 即 图 示人 中 
的 倒 三 角 (代号 为 “F2.X”) 标识 的 反 向 提交 ， 将 功能 2 的 所 有 历史 提 
交 全 部 撤销 。 


. 图 示 @@ 表 示 除 了 功能 2 外 的 其 他 开发 继续 进行 。 


那么 负责 开发 功能 2 的 开发 者 干什么 呢 ? 或 者 放 一 个 长 假 ， 或 者 在 


本 地 开发 ， 与 版 本 库 隅 离 ， 即 不 同 版 本 库 提 交 ， 直 到 延期 的 项 目 终于 发 
布 之 后 再 将 代码 提交 。 这 两 种 方法 都 是 不 可 取 的 ， 尤 其 是 后 一 种 隅 离开 
发 最 危险 ， 如 果 因 为 病毒 感染 、 文 件 误 删 、 磁 盘 损 坏 ， 就 会 导致 全 部 工 
作 损 失 殉 尽 。 我 管理 过 的 一 个 项 目 组 就 曾经 遇 到 过 这 样 的 情况 。 

采用 分 文 将 某 个 功能 或 模块 的 开发 与 开发 主线 独立 出 来 ， 是 解决 类 
似 问 题 的 办 法 ， 这 种 用 途 的 分 文 被 称 为 特性 分 文 〈Feature Branch) 或 主 
题 分 文 (Topic Branch) 。 图 18-4 就 展示 了 如 何 使 用 特性 分 文 帮助 纠正 
要 延期 的 项 目 ， 协 同 多 用 户 的 开发 。 


YY es 


F2.1 F2.2 
2 
(© 大 G 
F1.1 F2.1 F1.2 F2.2 F2.X 
F2.1 F2.2 F2.3 
G) O 〇 O 〇 O 
F1.1 F2.1 F1.2 F2.2 F2.X F1.3 F1.4 F1.5 


图 18-4 使 用 特性 分 支 协同 多 功能 开发 


说 明 : 


` 图 18-4 中 的 图 示 ( 了 D 和 前 面 的 一 样 ， 都 是 多 个 开发 者 的 提交 混杂 在 
开发 主线 中 。 


` 图 示 @ 是 当 得 知 功能 2 不 在 此 次 产品 发 布 中 后 ， 功 能 2 的 开发 者 所 
做 的 操作 。 


“ 首先， 功能 2 的 开发 者 提交 一 个 (或 若干 个 ) 反 向 提交 ， 将 功能 2 
的 相关 代码 全 部 撤销 。 图 中 倒 三 角 (代号 为 “F2.X”) 的 提交 就 是 一 个 
反 向 提交 。 


接着， 功能 2 的 开发 者 从 反 向 提交 开始 创建 一 个 特性 分 支 。 


最 后 ， 功 能 2 的 开发 者 将 功能 2 的 历史 提交 拣选 到 特性 分 支 上 。 对 
于 Git 可 以 使 用 拣选 命令 git cherry-pick。 


` 图 示 (3) 中 可 以 看 出 包括 功能 2 在 内 的 所 有 功能 和 模块 都 继续 提 
交 ， 但 是 提交 的 分 支 各 不 相同 。 功 能 2 的 开发 者 将 代码 提交 到 特性 分 支 
上 ， 其 他 开发 者 还 提交 到 主线 上 。 


那么 在 什么 情况 下 使 用 特性 分 文 呢 ? 试验 性 、 探 索性 的 功能 开发 应 
该 为 其 建立 特性 分 文 。 功 能 复杂 、 开 发 周期 长 有 可 能 在 本 次 发 布 中 取 
消 ) 的 模块 应 该 为 其 建立 特性 分 支 。 会 更 改 软件 体系 架构 ， 破 坏 软 件 集 
成 ， 或 者 容易 导致 冲突 、 影 响 他 人 人 开 友 进度 的 模块 ， 应 该 为 其 建立 特性 
分 支 。 











在 使 用 CVS 或 Subversion 等 版 本 控制 系统 建立 分 支 时 ， 或 者 因为 太 
慢 (CVS) 或 者 因为 授权 原因 需要 找 管 理 员 进行 操作 ， 非 常 的 不 方便 。 





Git 的 分 文 管理 就 方便 多 了 ， 一 是 开发 者 可 以 在 本 地 版 本 库 中 随心 所 欲 
地 创建 分 文 ， 二 是 管理 员 可 以 对 共享 版 本 库 进 行 设置 多 许 开 发 者 创建 特 
定名 称 的 分 文 ， 这 样 开 有 者 的 本 地 分 文 可 以 推送 到 服务 器 实现 数据 的 备 
份 。 关 于 Git 服 务 器 的 分 文 授 权 参 照 本 书 第 5 篇 的 Gitolite 服 务 器 架设 的 相 


天 章节 。 


i813 芋 二 人 小 支 


有 的 项 目 要 引用 到 第 三 方 的 代码 模块 并 且 需 要 对 其 进行 定制 ， 有 的 
项 目 甚至 整个 就 是 基于 茶 个 开源 项 目 进行 的 定制 。 如 何 有 效 地 管理 本 地 
定制 和 第 三 方 ( 上 游 ) 代 码 的 变更 就 成 为 了 一 个 难题 。 卖 主 分 文 
(Vendor Branch) 可 以 部 分 解决 这 个 难题 。 


所 谓 卖 主 分 文 ， 就 是 在 版 本 库 中 创建 一 个 专门 和 上 游 代码 进行 同步 


的 分 支 ， 一 旦 有 上 游 代 码 发 布 就 检 入 到 卖主 分 文中 。 图 18-5 束 是 一 个 典 
型 的 夹 主 分 文 工 作 流程 。 





vi.0 Ch c2 M1 c3 c4 c98 c99 M2 


图 18-5 卖主 分 支 工 作 流 程 


说 明 : 


. 在 主线 上 检 入 上 游 软件 版 本 1.0 的 代码 。 在 图 中 标记 为 v1.0 的 提交 
即 是 。 
然后 在 主线 上 进行 定制 开发 ，cl1、c2 分 别 代 表 历 次 定制 提交 。 


. 当 上 游 有 了 新 版 本 发 布 后 ， 例 如 2.0 版 本 ， 就 将 上 游 新 版 本 的 源 代 


码 提交 到 卖主 分 支 中 。 图 中 标记 为 v2.0 的 提交 即 是 。 


" 然后 在 主线 上 合并 卖主 分 支 上 的 新 提交 ， 合 并 后 的 提交 显示 为 


M1。 
如 果 定 制 较 少 ， 使 用 卖主 分 文 可 以 工作 得 很 好 ， 但 是 如 果 定 制 的 内 


容 非 常 多 ， 在 合并 的 时 候 就 会 遇 到 非常 多 的 冲突 。 定 制 的 代码 越 多 、 泥 
杂 的 越 历 害 ， 冲 突 解决 就 越 困 难 。 





本 草 的 内 容 尚 不 能 针对 复杂 的 定制 开发 给 出 满意 的 版 本 控制 解决 方 
案 ， 本 书 第 4 访 的 “第 22 革 ”Topgit 协 同 模型 "会 介绍 一 个 针对 复杂 定制 开 
发 的 更 好 的 解决 方案 。 


18.2 ”分 文 命令 概述 


在 Git 中 分 支管 理 使 用 命令 git branch。 该 命令 的 主要 用 法 如 下 : 














用 法 1: git branch 

用 法 2: git branch <branchname> 

用 法 3: git branch <branchname> <start-point> 
用 法 4: git branch -d <branchname> 

用 法 5: git branch -D <branchname> 

用 法 6: git branch -m <oldbranch> <newbranch> 
用 法 7: git branch -M <oldbranch> <newbranch> 






























































. 用 法 1 用 于 显示 本 地 分 支 列 表 。 当 前 分 支 在 输出 中 会 显示 为 特别 
的 颜色 ， 并 用 星 号 “*” 标 识 出 来 。 


. 用 法 2 和 用 法 3 用 于 创建 分 支 。 用 法 2 基于 当前 头 指 针 (HEAD) 
指向 的 提交 创建 分 支 ， 新 分 支 的 分 支 名 为 。 用 法 3 基于 提交 创建 新 分 
支 ， 新 分 支 的 分 支 名 为 。 

. 用 法 4 和 用 法 5 用 于 删除 分 支 。 用 法 4 在 删除 分 支 时 会 检查 所 要 删 
除 的 分 支 是 否 已 经 合并 到 其 他 分 支 中 ， 否则 拒绝 删除 。 用 法 5 会 强制 市 


除 分 支 ， 即 使 该 分 支 没有 合并 到 任何 一 个 分 支 中 。 


. 用 法 6 和 用 法 7 用 于 重 命名 分 支 。 如 果 版 本 库 中 已 经 存在 名 为 的 分 
支 ， 用 法 6 拒绝 执行 重 命名 ， 而 用 法 7 会 强制 执行 。 


下 面 就 通过 “Hello World” 项 目 演示 Git 的 分 支管 理 。 


18.3 “Hello World” 开 发 计划 


上 一 章 从 Github 1 上 检 出 的 hello-world 包 含 了 一 个 C 语 言 开发 的 应 
用 ， 现 在 假设 项 目 hello-world 做 产品 发 布 ， 版 本 号 定 为 1.0， 则 进行 下 面 
的 里 程 碑 操作 。 


(1) 为 hello-world 创 建 里 程 碑 v1.0。 





$ cd /path/to/user1i/workspace/hello-world/ 
$ git tag -m "Release 1.0" v1.0 





(2) 将 新 建 的 里 程 碑 推送 到 远程 共享 版 本 库 。 





$ git push origin refs/tags/v1.0 
Counting objects: 1, done. 
Writing objects: 100% (1/1), 158 bytes, done. 
Total 1 (delta 0), reused 0 (delta 0) 
Unpacking objects: 100% (1/1), done. 
To file:///path/to/repos/hello-world.git 

* [new tag] V1.0 -> v1.0 





到 现在 为 止 还 没有 运行 hello-world 程 序 呢 ， 现 在 就 在 开发 者 user1 的 
工作 区 中 运行 一 下 ， 具 体操 作 过 程 如 下 。 








(1) 进入 src 目 录 ， 编 译 程序 。 





$ cd src 

$ make 

version.h.in => version.h 
cc -C -0 main.o main.c 


cc -0 hello main.o 





(2) 使 用 参数 --help 运 行 hello 程 序 ， 可 以 查看 帮助 信息 。 


说 明 : hello 程 序 的 帮助 输出 中 有 一 个 拼写 错误 ， 本 应 该 是 --help 的 
地 方 写成 了 -help。 这 是 有 意 为 之 。 





$ ./hello --help 
Hello world example v1.0 
Copyright Jiang Xin <jiangxin AT ossxp DOT com>, 2009. 
Usage: 
hello 
say hello to the world. 
hello <username> 
say hi to the user. 
hello -h, -help 
this help screen. 





(3) 不 禹 参数 运行 ， 回 全 世界 问候 。 











说 明 : 最 后 一 行 显示 版 本 为 “v1.0”， 这 显然 是 来 自 于 新 建立 的 里 程 
人 碑 “v1.0” Oo 





$ ./hello 
Hello worild. 
(version: v1.0) 





(4) 执行 命令 的 时 候 ， 后 面 添加 用 户 名 作为 参数 ， 则 同 该 用 户 问 
候 。 


说 明 : 下 面 在 运行 hello 的 时 候 ， 显 然 出 现 了 一 个 Bug， 即 用 户 名 中 
间 如 有 果 出 现 了 空格 ， 输 出 的 欢迎 信息 只 包含 了 部 分 的 用 户 名 。 这 个 Bug 
也 是 有 意 为 之 。 








$ ./hello Jiang Xin 
Hi, Jiang， 
(version: v1.0) 





既然 1.0 版 本 已 经 发 布 了 ， 现 在 是 时 候 制订 下 一 个 版 本 2.0 的 开发 计 
划 了 。 计 划 如 下 : 


` 多 语种 支持 。 


为 hello-world 添 加 多 语种 文 持 ， 使 得 软件 运行 的 时 候 能 够 使 用 中 文 
或 其 他 本 地 化 语言 进行 问候 。 


对 命令 行 参 数 解 析 框 架 进 行 改造 ， 以 便 实现 更 姑 活 、 更 易 扩 展 的 命 
令 行 处 理 。 在 1.0 版 本 中 ， 程 序 内 部 解析 命令 行 参 数 使 用 了 简单 的 字符 
串 比 较 ， 非 常 不 灵活 。 从 源 文件 srcmain.c 中 可 以 看 到 当前 实现 的 简陋 和 
局 限 。 








$ git grep -n argv 

main.c:20:main(int argc， char **argv) 

main.c:24: } else if ( strcmp(argv[1], "-h") == 0 || 
main.c:25: strcemp(argv[1], "--help") == 0 ) { 
main.c:28: printf ("Hi, %s.\n", argv[1]); 





最 终 决 定 由 开发 者 user2 负 责 多 语种 文 持 的 功能 ， 由 开发 者 user1 人 负 
责 用 getopt 进 行 命令 行 解析 的 功能 。 


[1] https:/ /github.com/ossxp-com/hello-wotrld/ 


18.4 基于 特性 分 文 的 开发 





有 了 前 面 “ 代 码 管理 之 殉 ” 的 铺垫 ， 在 领受 任务 之 后 ， 开 发 者 user1 和 
user2 应 该 为 目 己 负责 的 功能 创建 特性 分 文 。 


18.4.1 创建 分 文 userl/getopt 


开发 者 user1 负 责 用 getopt 进 行 命令 行 解析 的 功能 ， 因 为 这 个 功能 
到 getopt 函 数 ， 于 是 将 这 个 分 文 命名 为 userl/getopt。 开 发 者 userl 使 用 git 
branch 命 令 创建 该 特性 分 文 ， 有 具体 操作 过 程 如 下 。 


(1) 确保 是 在 开发 者 userl 的 工作 区 中 。 





$ cd /path/to/user1i/workspace/hello-world/ 





(2) 开发 者 user1 基 于 当前 HEAD 创 建 分 支 userl/getopt。 





$ git branch user1i/getopt 





(3) 使 用 git branch 创 建 分 支 ， 并 不 会 目 动 切换 。 查 看 当前 分 支 可 
以 看 到 仍然 工作 在 master 分 文 〈 用 星 号 “#” 标 识 ) 中 。 








$ git branch 
* master 
user1i/getopt 





(4) 执行 git checkout 命 令 切 换 到 新 分 文 上 。 





$ git checkout user1i/getopt 
Switched to branch 'useri/getopt' 











(5) 再 次 查看 分 文 列 表 ， 当 前 工作 分 文 的 标记 符 《〈 星 号 ) 已 经 落 
在 userl/getopt 分 支 上 。 





$ git branch 
master 
* User1i/getopt 





分 支 实际 上 是 创建 在 目录 .git/refs/heads 下 的 引用 ， 版 本 库 初 始 时 创 
建 的 master 分 支承 是 在 该 目录 下 。 在 第 2 篇 “第 7 章 Git 重 置 > 的 章节 中 ， 已 
经 介绍 过 master 分 文 的 实现 ， 实 际 上 这 也 是 所 有 分 支 的 实现 方式 。 











. 查看 一 下 .git/refs/heads 目 录 下 的 引用 。 可 以 在 该 目录 下 看 到 
mastet 文 件 ， 和 一 个 user1 目 录 。 而 在 user1 目 录 下 是 文件 getopt。 





$ ls -F .git/refs/heads/ 
master useri1/ 

$ ls -F .git/refs/heads/user1/ 
getopt 





* 引用 文件 .git/refs/heads/user1l/getopt 记 录 的 是 一 个 提交 ID。 





$ cat .git/refs/heads/user1i/getopt 
ebcf6d6b06545331df156687ca2940800a3c599d 





~ 


- 因为 分 支 user1/getopt 是 基于 头 指 针 HEAD 创 建 的 ， 因 此 当前 该 分 
支 和 mastef 分 支 的 指向 是 一 致 的 。 





$ cat .git/refs/heads/master 
ebcf6d6b06545331df156687ca2940800a3c599d 





. 当前 的 工作 分 支 为 uset1/getopt， 记 录 在 头 指 针 文 件 .gtt/HEAD 
中 © 


切换 分 文 命令 git checkout 对 文件 .giyHEAD 的 内 容 进 行 更 新 。 可 以 


参照 第 2 篇 “第 8 章 ”Git 检 出 ”的 相关 章节 。 





$ cat .git/HEAD 
ref: refs/heads/user1i/getopt 





18.4.2 ”创建 分 文 user2/i18n 


开发 者 user2 要 完成 多 语种 支持 的 工作 任务 ， 于 是 决定 将 分 支 定 名 为 
user2/il8n。 每 一 次 创建 分 文通 钊 都 需要 完成 以 下 两 个 工作 : 





` 创建 分 支 : 执行 git branch 命 令 创 建新 分 支 。 
` 切换 分 支 : 执行 git checkout 命 令 切 换 到 新 分 支 。 


有 没有 简单 的 操作 ， 在 创建 分 文 后 立即 切换 到 新 分 文 上 呢 ? 有 的 ， 


Git 提 供 了 这 样 一 个 命令 ， 能 够 将 上 述 两 条 命令 所 执行 的 操作 一 次 性 完 


成 。 用 法 如 下 : 





git checkout -b <new_branch> [<start_point>] 





即 检 出 命令 git checkout 通 过 参数 -b<new_branch> 实 现 了 创建 分 支 和 
切换 分 支 两 个 动作 的 合 二 为 一 。 下 面 开 发 者 user2 就 使 用 git checkout 命 令 
来 创建 分 文 ， 有 具体 操作 过 程 如 下 。 


(1) 进入 到 开发 者 user2 的 工作 目录 ， 并 和 上 游 同步 一 次 。 





$ cd /path/to/user2/workspace/hello-world/ 
$ git pull 
remote: Counting objects: 1, done. 
remote: Total 1 (delta 0), reused 0 (delta 0) 
Unpacking objects: 100% (1/1), done. 
From file:///path/to/repos/hello-world 
* [new tag] v1.0 -> v1.0 
Already up-to-date. 





(2) 执行 git checkout-b 命 令 ， 创 建 并 切换 到 新 分 文 user2/il8n 上 。 





$ git checkout -b user2/ii8n 
Switched to a new branch 'user2/i1i8n' 











(3) 查看 本 地 分 支 列 表 ， 会 看 到 已 经 创建 并 切换 到 user2/i18n 分 支 
上 了 。 





$ git branch 
master 
* User2/ili8n 





18.4.3 ”开发 者 userl 完 成 功能 开发 


开发 者 user1 开 始 在 userlgetopt 分 支 中 工作 ， 重 构 hello-world 中 的 命 
村 参数 解析 的 代码 。 重 构 时 采用 getopt long 函数 。 


您 可 以 试 着 更 改 ， 不 过 在 hello-world 中 已 经 保存 了 一 份 改 好 的 代 
码 ， 可 以 直接 检 出 。 





(1) 确保 是 在 user1 的 工作 区 中 。 





$ cd /path/to/user1i/workspace/hello-world/ 





(2) 执行 下 面 的 命令 ， 用 里 程 碑 jx/v2.0 标 记 的 内 容 ( 己 实现 用 
getopt 进 行 命令 行 解析 的 功能 ) 蔡 换 和 暂 存 区 和 工作 区 。 








下 面 的 git checkout 命 令 的 最 后 是 一 个 点 “.”， 因 此 检 出 只 更 改 了 和 暂 存 
区 和 工作 区 ， 而 没有 修改 头 指针 。 





$ cd ee -world/ 
$ git checkout jx/v2.0 -- 





(3) 查看 状态 ， 会 看 到 分 支 仍 保持 为 userl/getopt， 但 文件 
src/main.c 被 修改 了 。 





$ git status 

# On branch user1i/getopt 

# Changes to be committed: 

# (use "git reset HEAD <file>..." to unstage) 


modified: src/main.c 


亲 亲 六 





(4) 比较 暂 存 区 和 HEAD 的 文件 差 寞 ， 可 以 看 到 为 实现 用 getopt 进 
行 命令 行 解析 功能 而 对 代码 的 改动 。 





$ git diff --cached 
diff --git a/src/main.c b/src/main.c 
index 6ee936f..fa5244a 100644 

--- a/src/main.c 
+++ b/src/main.c 
QQ -1, 4 +1, 6 @@ 

#include <stdio.h> 
+#include <getopt.h> 
十 

#include "version.h" 

int usage(int code) 
@@ -19, 15 +21, 44 QQ int usage(int code) 
int 

main(int argc, char **argv) 

{ 
if (argc == 1) { 
int c; 
char *uname = NULL; 


while (1) { 
int option_ index = 0; 
static struct option Jong_options[] = { 
{"help", 0, 0, ‘'h'}, 
{0, 0, 0, 0} 
}; 


+ 二 + 十 十 二 十 十 二 十 ，! 





(5) 开发 者 user1 提 交代 码 ， 完 成 开发 任务 。 





$ git commit -m "Refactor: use getopt_ long for arguments parsing." 
[useri/getopt ©0881ca3] Refactor: use getopt_long for arguments parsing. 
1 files changed, 36 insertions(+), 5 deletions(-) 





(6) 提交 完成 之 后 ， 可 以 看 到 这 时 userl/getopt 分 文 和 master 分 文 的 
指向 不 同 了 。 





$ git rev-parse useri/getopt master 
©0881ca3f62ddadcddec08bd9f2f529a44d17cfbf 
ebcf6d6b06545331df156687ca2940800a3c599d 





(7) 编译 运行 hello-world。 


注意 输出 中 的 版 本 号 显示 





$ cd src 

$ make clean 

rm -f hello main.o version.h 
$ make 

version.h.in => version.h 

cc -C -0 main.o main.c 

cc -0 hello main.o 

$ ./hello 

Hello world. 

(version: v1.0-1-g0881ca3) 





18.4.4 ”将 userl/getopt 分 支 合并 到 主线 


既然 开发 者 user1l 负 责 的 功能 开发 完成 了 ， 那 束 合 并 到 开发 主线 
master 上 吧 ， 这 样 测试 团队 (如 果 有 的 话 ) 束 可 以 基于 开发 主线 master 
进行 软件 集成 和 测试 了 。 有 具体 操作 过 程 如 下 。 


(1) 为 将 分 文 合 并 到 主线 ， 首 先 user1 将 工作 区 切换 到 主线 ， 即 


master 分 支 。 





$ git checkout master 
Switched to branch 'master' 





(2) 然后 执行 git merge 命 令 以 合并 userl/getopt 分 支 。 





$ git merge user1i/getopt 

Updating ebcf6d6. .0881ca3 

Fast-forward 
src/main.c | 441 二 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 二 十- - - - - 
1 files changed, 36 insertions(+), 5 deletions(-) 





(3) 本 次 合并 非常 顺利 ， 实 际 上 合并 后 master 分 文 和 userl/getopt 指 
向 同一 个 提交 。 这 是 因为 合并 前 的 master 分 支 的 提交 就 是 usrl/getopt 分 支 


父 提 交 ， 所 以 此 次 合并 相当 于 将 分 文 master 重 置 到 userl/getopt 分 文 。 


Ey 





$ git rev-parse useri/getopt master 
0881ca3f62ddadcddec08bd9f2f529a44d17cfbf 
0881ca3f62ddadcddec08bd9f2f529a44d17cfbf 





(4) 查看 状态 信息 可 以 看 到 本 地 分 支 和 远程 分 支 的 跟踪 关系 。 





$ git status 

# On branch master 

# Your branch is ahead of 'origin/master' by 1 commit. 
# 

nothing to commit (working directory clean) 





(5) 上面 的 状态 输出 中 显示 本 地 master 分 支 比 远程 共享 版 本 库 的 
master 分 支 领 先 ， 可 以 运行 git cherry 命 令 查 看 哪些 提交 领先 (未 被 推送 
到 上 游 跟踪 分 文中 ) 。 





$ git cherry 
+ 0881ca3f62ddadcddec0o8bd9f2f529a44d17cfbf 





(6) 执行 推送 操作 ， 完 成 本 地 分 支 向 远程 分 支 的 同步 。 





$ git push 
Counting objects: 7, done. 
Delta compression using up to 2 threads. 


Compressing objects: 100% (4/4), done. 

Writing objects: 100% (4/4), 689 bytes, done. 

Total 4 (delta 3), reused 0 (delta 0) 

Unpacking objects: 100% (4/4), done. 

To file:///path/to/repos/hello-world.git 
ebcf6d6. .0881ca3 master -> master 





(7) 删除 userl/getopt 分 文 。 


既然 特性 分 支 userl/getopt 已 经 合并 到 主线 上 了 ， 那 么 该 分 支 已 经 
成 了 历史 使 命 ， 可 以 放心 地 将 其 删除 。 


dl 





$ git branch -d user1i/getopt 
Deleted branch useri/getopt (was 0881ca3). 





开发 者 user2 对 多 语种 支持 功能 有 些 犯 秋 ， 需 要 多 人 花 些 时 间 ， 那 么 束 
先 不 等 他 了 。 





18.5 天 于 吧 布 个 广 的 开 肥 
用 户 在 使 用 1.0 版 的 hello-world 过 程 中 发 现 了 两 个 错误 ， 报 告 给 项 目 
组 。 


“ 第 一 个 问题 是 : 帮助 信息 中 出 现 文字 错误 。 本 应 该 写 为 a 


help” 却 写成 了 “-help”。 


. 第 二 个 问题 是 : 当 执 行 hello-wotld 的 程序 ， 提 供 带 空格 的 用 户 名 


时 ， 问 候 语 中 显示 的 是 不 完整 的 用 户 名 。 


例如 执行 “./hello Jiang Xin”， 本 应 该 输出 “Hi，Jiang Xin.”， 却 只 输 
出 了 “Hi，Jiang.”。 


为 了 能 够 及 时 修正 1.0 版 本 中 存在 的 这 两 个 Bug， 将 这 两 个 Bug 的 修 
正 工 作 分 别 交 给 两 个 开发 者 user1 和 user2 完 成 : 


* 开发 者 usef1 负 责 修 改 文字 错误 的 Bug。 
. 开发 者 user2 负 责 修 改 显 示 用 户 名 不 完整 的 bug。 


现在 的 版 本 库 中 master 分 支 相 比 1.0 发 布 时 添加 了 新 功能 代码 ， 即 开 
发 者 user1l 推 送 的 用 getopt 进 行 命令 行 解析 的 相关 代码 。 如 果 基 于 master 
分 文 对 用 户 报告 的 两 个 Bug 进 行 修改 ， 就 会 引入 尚未 经 过 测试 、 可 能 不 


稳定 的 新 功能 的 代码 。 在 之 前 “代码 管理 之 殉 ” 中 介绍 的 发 布 分 文 ， 恰 恰 
适用 于 此 场景 。 


18.5.1 创建 发 布 分 支 


要 想 解 决 在 1.0 版 本 中 发 现 的 Bug， 束 需要 基于 1.0 发 行 版 的 代码 创建 





(1) 软件 hello-world 的 1.0 发 布 版 在 版 本 库 中 有 一 个 里 程 碑 相对 
应 。 





$ cd /path/to/user1i/workspace/hello-world/ 
$ git tag -ni -1 v* 
v1.0 Release 1.0 





(2) 基于 里 程 碑 v1.0 创 建 发 布 分 支 hello-1.x。 


注 : 使 用 了 git checkout 命 令 创 建 分 支 ， 最 后 一 个 参数 v1.0 是 新 分 支 
hello-1.x 创 建 的 基准 点 。 如 果 没 有 里 程 碑 ， 使 用 提交 ID 也 是 一 样 。 





$ git checkout -b hello-1.x v1.0 
Switched to a new branch 'hello-1.x' 





(3) 用 git rev-parse 命 令 可 以 看 到 hello-1.x 分 支 对 应 的 提交 JD 和 里 程 
碑 V1.0 指 癌 的 提交 一 致 ， 但 是 和 master 不 一 样 。 


提示 : 因为 里 程 碑 v1.0 是 一 个 包 合 提交 说 明 的 里 程 碑 ， 因 此 为 了 时 


示 其 对 应 的 提交 ID， 使 用 了 特别 的 记 法 “v1.0^{}”。 





$ git rev-parse hello-1.x v1i.0^{} master 
ebcf6d6b06545331df156687ca2940800a3c599d 
ebcf6d6b06545331df156687ca2940800a3c599d 
0881ca3f62ddadcddec08bd9f2f529a44d17cfbf 





(4) 开发 者 userl 将 分 文 hello-1.x 推 送 到 远程 共享 版 本 库 ， 因 为 开 
发 者 user2 修 改 Bug 时 也 要 用 到 该 分 文 。 





$ git push origin hello-1.x 
Total 0 (delta 0), reused 0 (delta 0) 
To file:///path/to/repos/hello-world.git 
* [new branch] hello-1.x -> hello-1.x 





(5) 开发 者 user2 从 远程 共 孚 版 本 库 获 取 新 的 分 文 。 


开发 者 user2 执 行 git fetch 命 令 ， 将 远程 共享 版 本 库 的 新 分 文 hello-1.x 
复制 到 本 地 引用 origin/hello-1.x 1 上。 





$ cd /path/to/user2/workspace/hello-world/ 


$ git fetch 
From file:///path/to/repos/hello-world 
* [new branch] hello-1.x -> origin/hello-1.x 





(6) 开发 者 user2 切 换 到 hello-1.x 分 文 。 


本 地 引用 originmhello-1.x 称 为 远程 分 文 ， 第 19 章 将 专题 介绍 。 该 远 
程 分 支 不 能 直接 检 出 ， 而 是 需要 基于 该 远程 分 支 创 建 本 地 分 文 。 第 19 章 
会 介绍 一 个 更 为 简单 的 基于 远程 分 文 建立 本 地 分 支 的 方法 ， 本 例 先 用 标 
准 的 方法 建立 分 文 。 











$ git checkout -b hello-1.x origin/hello-1.x 
Branch hello-1.x set up to track remote branch hello-1.x from origin. 
Switched to a new branch 'hello-1.x' 








18.5.2 ”开发 者 user1l 工 作 在 发 布 分 支 


开发 者 user1 修 改 帮 助 信息 中 的 文字 错误 ， 具 体操 作 过 程 如 下 。 


(1) 编辑 文件 src/main.c， 将 “-help” 字 符 串 修改 为 “--help”。 





$ cd /path/to/user1i/workspace/hello-world/ 
$ vi src/main.c 





(2) 开发 者 userl 的 改动 可 以 从 下 面 的 差异 比较 中 看 到 。 





$ git diff 
diff --git a/src/main.c b/src/main.c 
index 6ee936f. .e76f05e 100644 
--- a/src/main.c 
+++ b/src/main.c 
@@ -11, 7 +11, 7 @@ int usage(int code) 
由 Say hello to the world.\n\n" 
四 hello <username>\n" 
由 say hi to the user.\n\n" 
- hello -h, -help\n" 
+ 机 hello -h, --help\n" 
i this help screen.\n\n", _VERSION); 
return code; 





(3) 执行 提交 。 





$ git add -u 
$ git commit -m "Fix typo: -help to --help." 
[hello-1.x b56bb51] Fix typo: -help to --help. 

1 files changed, 1 insertions(+), 1 deletions(-) 





(4) 推送 到 远程 共 孚 版 本 库 。 





$ git push 

Counting objects: 7, done. 

Delta compression using up to 2 threads. 

Compressing objects: 100% (4/4), done. 

Writing objects: 100% (4/4), 349 bytes, done. 

Total 4 (delta 3), reused 0 (delta 0) 

Unpacking objects: 100% (4/4), done. 

To file:///path/to/repos/hello-world.git 
ebcf6d6..b56bb51 hello-1i.x -> hello-1.x 








18.5.3 ”开发 者 user2 工 作 在 发 布 分 支 


开发 者 user2 针 对 问候 时 用 户 名 显示 不 全 的 Bug 进 行 更 改 ， 具 体操 作 
过 程 如 下 。 


(1) 进入 开发 者 user2 的 工作 区 ， 并 确保 工作 在 hello-1.x 分 支 中 。 





$ cd /path/to/user2/workspace/hello-world/ 
$ git checkout hello-1.x 





(2) 编辑 文件 src/main.c， 修 改 代码 中 的 Bug。 





$ vi src/main.c 





(3) 实际 上 在 hello-world 版 本 库 中 包含 了 我 的 一 份 修改 ， 可 以 看 看 
和 您 的 更 改 是 否 一 致 。 


下 面 的 命令 将 我 对 此 Bug 的 修改 保存 为 一 个 补丁 文件 。 





$ git format-patch jx/v1.1..jx/v1i.2 
©0001-Bugfix-allow-spaces-in-username.patch 





(4) 应 用 我 对 此 Bug 的 改动 补丁 时。 


如 末 您 已 经 目 己 完成 了 修改 ， 可 以 先 执行 git stash 保 存 目 己 的 修改 
进度 ， 然 后 执行 下 面 的 命令 应 用 补丁 文件 。 当 应 用 完 补 丁 后， 再 执行 git 
stash pop 将 您 的 改动 合并 到 工作 区 。 如 果 我 们 的 改动 一 臻 《英雄 所 见 略 
同 ) ， 将 不 会 有 冲突 。 











$ patch -p1 < 0001-Bugfix-allow-spaces-in-username.patch 
patching file src/main.c 





(5) 看 看 代码 的 改动 吧 。 





$ git diff 
diff --git a/src/main.c b/src/main.c 
index 6ee936f, .fof404b 100644 
- a/src/main.c 
+++ b/src/main.c 
@@ -19, 13 +19, 20 @@ int usage(int code) 
int 
main(int argc， char **argv) 


+ char **p = NULL; 


十 
if (argc == 1) { 
printf ("Hello world.\n"); 

} else if ( strcmp(argv[1], "-h") == 0 || 
strcmp(argv[1], "--help") == 0 ) { 
return usage(0); 

} else { 

- printf ("Hi, %s.\n", argv[1]); 
十 p = &argv[1]; 

+ printf ("Hi, "); 

+ do 工 

十 printf ("”%s"， *p); 

十 } while (*(++p)); 

+ printf (".\n"); 


} 
printf( "(version: %s)\n", _VERSION ); 


ee | 





(6) 本 地 测试 一 下 改进 后 的 软件 ， 看 看 Bug 是 否 已 经 被 改正 。 如 琳 
运行 结果 能 显示 出 完整 的 用 户 名 ， 则 Bug 成 功 修正 。 








$ cd src/ 

$ make 

version.h,in => version.h 
cc -C -0 main.o main.c 


cc -0 hello main.o 

$ ./hello Jiang Xin 
Hi, Jiang Xin. 
(version: v1.0-dirty) 





(77 提交 人 但 ， 





$ git add -u 

$ git commit -m "Bugfix: allow spaces in username." 
[hello-1.x e64f3a2] Bugfix: allow spaces in username. 
1 files changed, 8 insertions(+), 1 deletions(-) 





18.5.4 ”开发 者 user2 合 并 推送 





开发 者 user2 在 本 地 版 本 库 完 成 提交 后 ， 不 要 忘记 向 远程 共享 版 本 库 
进行 推送 。 但 在 推送 分 支 hello-1.x 时 开发 者 user2 没 有 开发 者 userl 那 么 幸 
运 ， 因 为 此 时 远程 共享 版 本 库 的 hello-1.x 分 支 已 经 被 开发 者 user1 推 送 过 
一 次 ， 因 此 开发 者 user2 在 推送 过 程 中 会 遇 到 非 快 进 式 推 送 问题 。 





$ git push 
To file:///path/to/repos/hello-world.git 
! [rejected] hello-1.x -> hello-1.x (non-fast-forward) 


error: failed to push some refs to 'file:///path/to/repos/hello-world.git' 
To prevent you from losing history, non-fast-forward updates were rejected 
Merge the remote changes (e.g. 'git pull') before pushing again. See the 
'Note about fast-forwards' section of 'git push --help' for details. 


= 


就 像 在 “第 15 草 。Git 协 议和 工作 协同 ”一 草 中 介绍 的 那样 ， 开 发 者 
user2 需 要 执行 一 个 拉 回 操作 ， 将 远程 共 至 服务 器 的 改动 获取 到 本 地 并 和 
本 地 提交 进行 合并 。 





$ git pull 

remote: Counting objects: 7, done. 

remote: Compressing objects: 100% (4/4), done. 
remote: Total 4 (delta 3), reused 0 (delta 0) 
Unpacking objects: 100% (4/4), done. 
From file:///path/to/repos/hello-world 

ebcf6d6..b56bb51 hello-1i.x -> origin/hello-1.x 

Auto-merging src/main.c 
Merge made by recursive. 

src/main.c | 2 +- 

1 files changed, 1 insertions(+), 1 deletions(-) 





通过 显示 分 文 图 的 方式 碍 看 日 志 ， 可 以 看 到 在 执行 git pull 操 作 后 发 
和 人 





$ git 1og --graph --oneline 


8cffe5f Merge branch ‘hello-1.x' of file:///path/to/repos/hello-world into hellc 
| 

| * b56bb51 Fix typo: -help to --help. 

* | e64f3a2 Bugfix: allow spaces in username. 

I/ 

* ebcf6d6 blank commit for GnuPG-signed tag test. 

* 8a9f3d1 blank commit for annotated tag test. 

* 60a2f4f blank commit. 

* 3e6070e Show version. 

* 


75346b3 Hello world initialized. 





现在 开发 者 user2 可 以 将 合并 后 的 本 地 版 本 库 中 的 提交 推送 给 远程 共 
诗 版 本 库 了 。 





$ git push 

Counting objects: 14, done. 

Delta compression using up to 2 threads. 
Compressing objects: 100% (8/8), done. 
Writing objects: 100% (8/8), 814 bytes, done. 
Total 8 (delta 6), reused 0 (delta 0) 


Unpacking objects: 100% (8/8), done. 
To file:///path/to/repos/hello-world.git 
b56bb51..8cffe5f hello-1i.x -> hello-1.x 


18.5.5 发 布 分 文 的 提交 合 着 到 主 贫 


当 开 发 者 user1 和 user2 都 相继 在 hello-1.x 分 支 中 将 相应 的 Bug 修 改 完 
后 ， 就 可 以 从 hello-1.x 分 文中 编译 新 的 软件 产品 交 给 客户 使 用 了 。 接 下 
来 别 筷 了 在 主线 master 分 文中 也 做 出 同样 的 更 改 ， 因 为 在 hello-1.X 分 支 
中 修改 的 Bug 同 样 也 存在 于 主线 master 分 文中 。 


1. 拒 选 操作 


使 用 Git 提 供 的 拣选 命令 ， 就 可 以 直接 将 发 布 分 文 上 进行 的 Bug 修 正 
合并 到 主线 上 。 下 面 就 以 开发 者 user2 的 号 份 进行 操作 ， 有 基体 操作 过 程 如 
Ps 


(1) 进入 user2 工 作 区 并 切换 到 master 分 支 。 


$ cd /path/to/user2/workspace/hello-world/ 
$ git checkout master 





(2) 从 远程 共享 版 本 库 同步 master 分 支 。 


同步 后 本 地 master 分 文 包含 了 开发 者 user1 提 交 的 命令 行 参 数 解析 重 
构 的 代码 。 


$ git pull 

remote: Counting objects: 7, done. 

remote: Compressing objects: 100% (4/4), done. 
remote: Total 4 (delta 3), reused 0 (delta 0) 
Unpacking objects: 100% (4/4), done. 

From file:///path/to/repos/hello-world 

ebcf6d6..0881ca3 master -> origin/master 

Updating ebcf6d6. ,0881ca3 
Fast-forward 

src/main.c | 441 二 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 二 十- - - - - 
1 files changed, 36 insertions(+)， 5 deletions(-) 





(3) 碍 看 分 文 hello-1.x 的 日 志 ， 确 认 要 拣选 的 提交 ID。 





从 下 面 的 日 志 中 可 以 看 出 分 支 hello-1.x 的 最 新 提交 是 一 个 合并 提 
而 要 拣选 的 提交 分 别 是 其 第 一 个 父 提 交 和 第 二 个 父 提 交 ， 可 以 分 别 
用 “hello-1.x^1” 和 “hello-1.x^2” 表 示 。 





$ git log -3 --graph --oneline hello-1.x 

的 8cffe5f Merge branch ‘'hello-1.x' of file:///path/to/repos/hello-world into hellc 
|\ 

| * b56bb51 Fix typo: -help to --help. 


* | e64f3a2 Bugfix: allow spaces in username. 
I/ 





(4) 执行 拣选 操作 。 先 将 开发 者 user2 提 交 的 修正 代码 拣选 到 当前 
分 文 《 即 主线 ) 。 


拣选 操作 遇 到 了 训 突 ， 见 下 面 的 命令 输出 。 





$ git cherry-pick hello-1.x^1 
Automatic cherry-pick failed. After resolving the conflicts, 
mark the corrected paths with 'git add <paths>' or 'git rm <paths>" 
and commit the result with: 
git commit -c e64f3a216d346669b85807ffcfb23a21f9c5c187 





(5) 拣选 操作 发 生 冲 突 ， 通 过 碍 看 状态 可 以 看 到 是 在 文件 


src/main.c 上 发 生 了 冲突 。 





$ git status 
# On branch master 
# Unmerged paths: 


# (use "git reset HEAD <file>..." to unstage) 

# (use "git add/rm <file>..." as appropriate to mark resolution) 
# 

# both modified: src/main.c 

# 

no changes added to commit (use "git add" and/or "git commit -a") 





2. 冲 突 发 生 的 原因 


为 什么 发 生 了 冲突 呢 ? 这 是 因为 拣选 hello-1.x 分 文 上 的 一 个 提交 到 
master 分 文 时 ， 因 为 两 个 甚至 多 个 提交 在 重 登 的 位 置 更 改 代 码 所 致 。 通 
过 下 面 的 命令 可 以 看 到 到 后 是 哪些 提交 引起 的 冲突 。 








$ git log master...hello-1.x^1 
commit e64f3a216d346669b85807ffcfb23a21f9c5c187 
Author: user2 <user2@moon.ossxp.com> 
Date: Sun Jan 9 13:11:19 2011 +0800 
Bugfix: allow spaces in username. 
commit 0881ca3f62ddadcddec08bd9f2f529a44d17cfbf 
Author: user1 <user1iQ@sun.ossxp.com> 
Date: Mon Jan 3 22:44:52 2011 +0800 
Refactor: Use getopt_long for arguments parsing. 





可 以 看 出 引发 冲突 的 提交 一 个 是 当前 工作 分 文 master 上 的 最 新 提 
交 ， 即 开发 者 user1 的 重 构 命令 行 参数 解析 的 提交 ， 而 男 外 一 个 引发 冲突 
的 是 要 拣选 的 提交 ， 即 开发 者 user2 针 对 用 户 名 显示 不 全 所 做 的 错误 修正 
提交 。 一 定 是 因为 这 两 个 提交 的 更 改 发 生 了 重合 导致 了 冲突 的 发 生 。 下 
面 就 来 解决 冲突 。 








3. 冲 突 解 决 





冲突 解决 可 以 使 用 图 形 界 面 工具 ， 不 过 对 于 本 例 直 接 编 辑 冲 突 文 
件 ， 手 工 进 行 冲突 解决 也 很 方便 。 打 开 文 件 src/main.c 束 可 以 看 到 发 生 冲 
突 的 区 域 都 用 特有 的 标记 符 标 识 出 来 ， 参 见 表 18-1 中 左 侧 一 列 的 内 容 。 








表 18-1 冲突 解决 前 后 对 照 


冲 罕 文 件 src/main.c 标识 出 的 冲突 内 容 


21 int 

22 main(int argc, char **argv) 
23 { 

24 <<<<<<< HEAD 

25 intce; 

26 char*uname= NULL; 
27 

28 while (1) { 

29 int option_index = 0; 
30 static struct option long_options[] = { 
31 {"help", 0, 0, 'h'}, 
32 {0, 0, 0, 0} 

33 }; 

34 

35 c= getopt long(argc, argv, "h", 
36 long_options, &option_index); 
37 if (c==—1) 

38 break; 

39 

40 switch (c) { 

41 case 'h': 

42 return usage(0); 

43 default: 

4 return usage( 1); 

45 } 

46 } 

47 

48 if(optind <argc){ 

49 uname = argv[optind]; 
50 } 

51 

52 if(uname == NULL){ 
53 ===-== 一 

54 char**p= NULL; 

55 


56 f(arge=="]1){ 
57 >>>>>>> e64f3a2... Bugfix: allow spaces in username. 
58 printf ("Hello world.\n"); 


59 }elsef{ 

60 <<<<<<< HEAD 

61 printf ("Hi, %s.\n", uname); 
62 ======= 


63 p= &argv[1]; 

64 printf ("Hi,"); 

65 dof{ 

66 printf (" %s", *p); 

67 } while (*(++p)); 

68 printf ("\n"); 

69 >>>>>>> e64f3a2... Bugfix: allow spaces in username. 
70 } 

71 

72 printf "(version: %s)Nn"，VERSION ); 
73 return 0; 

74 } 


冲突 解决 后 的 内 容 对 照 


21 int 

22 main(int argc, char **argv) 

234 

24 int c; 

25 char**p= NULL; 

26 

27 while (1) { 

28 int option_index = 0; 

29 static struct option long_options[] = { 
30 {"help", 0, 0, 'h'}, 

31 {0, 0, 0, 0} 

32 }; 

33 

34 c= getopt long(argc, argv, "h", 
35 long_options, &option_index); 
36 if(c== -1) 

37 break; 

38 

39 switch (c) { 

40 case 'h': 

41 return usage(0); 

42 default: 

43 return usage( 1); 

44 } 

45 } 

46 


47 if(optind < argc) { 

48 p= &argv[optind]; 

49 } 

50 

51 if(p== NULL||*p== NULL)f{ 


52 printf ("Hello world.\n"); 
53 }else{ 


54 printf ("Hi,"); 

$5 dof 

56 printf (" %s", *p); 
57 } while (*(++p)); 
58 printf (".\n"); 


59 } 

60 

61 printf( "(version: %s)\n", VERSION ); 
62 return 0; 

63} 


在 文件 src/main.c 冲 突 内 容 中 ， 第 25-52 行 及 第 61 行 是 master 分 支 中 由 
开发 者 userl 香 构 命 令 行 解析 时 提交 的 内 容 ， 而 第 54~56 行 及 第 63-68 行 则 
是 分 文 hello-1.x 中 由 开发 者 user2 提 交 的 修正 用 户 名 显示 不 全 的 Bug 的 相 
应 代码 。 


表 18-1 右 侧 的 一 列 则 是 冲突 解决 后 的 内 容 。 为 了 和 冲突 前 的 内 容 相 
对 照 ， 重 新 进行 了 排版 ， 并 对 差异 内 容 进 行 加 粗 显 示 。 您 可 以 参照 完成 
冲突 解决 。 








六 





将 手动 编辑 完成 的 文件 src/main.c 深 加 a 到 暂 存 区 才 真 正 地 完成 了 冲突 





$ git add src/main.c 





因为 是 拣选 操作 ， 提 区 时 最 好 重用 所 拣选 提交 的 提交 次 明和 作者 信 
恩 ， 而 且 也 省 下 了 自己 写 提交 说 明 的 抹 烦 。 使 用 下 面 的 命令 完成 提交 操 
作 。 





$ git commit -C hello-1.x^1 
[master 10765a7] Bugfix: allow spaces in username. 
1 files changed, 8 insertions(+), 4 deletions(-) 





4. 完 成 全 部 拣选 操作 


接 下 来 再 将 开发 者 user1 在 分 支 hello-1.x 中 的 提交 也 扰 选 到 当前 分 
文 。 所 拣选 的 提交 非常 简单 ， 不 过 是 修改 了 提交 说 明 中 的 文字 错误 而 








己 ， 拒 选 操 作 也 不 会 引发 异 剃 ， 和 直接 完成 。 





$ git cherry-pick hello-1.x^2 
Finished one cherry-pick. 
[master d81896e] Fix typo: -help to --help. 
Author: user1 <useri@sun.ossxp.com> 
1 files changed, 1 insertions(+), 1 deletions(-) 








现在 通过 日 志 可 以 看 到 master 分 支 已 经 完成 了 对 已 知 Bug 的 修复 。 





git log -3 --graph --oneline 

d81896e Fix typo: -help to --help. 

10765a7 Bugfix: allow spaces in username. 

0881ca3 Refactor: use getopt_long for arguments parsing. 


+ * *{ 








得 看 状态 可 以 看 到 当前 的 工作 分 文 相对 于 远程 服务 器 有 两 个 新 提 





$ git status 

# On branch master 

# Your branch is ahead of 'origin/master' by 2 commits. 
# 

nothing to commit (working directory clean) 





执行 推送 命令 将 本 地 master 分 支 同 步 到 远程 共享 版 本 库 。 





$ git push 

Counting objects: 11, done. 

Delta compression using up to 2 threads. 

Compressing objects: 100% (8/8), done. 

Writing objects: 100% (8/8), 802 bytes, done. 

Total 8 (delta 6), reused 0 (delta 0) 

Unpacking objects: 100% (8/8), done. 

To file:///path/to/repos/hello-world.git 
0881ca3..d81896e master -> master 





[1 该 引用 的 全 称 为 refs/remotes/origin/hello-1.x。 


成 文人 ? 区 使 a 命令 这 里 六 


简单 起 见 使 用 GNU patch 命 令 。 


18.6 分 支 变 基 


18.6.1 ”完成 user2/i18n 特 性 分 支 的 开发 


开发 者 user2 针 对 多 语种 开发 的 工作 任务 还 没有 介绍 呢 ， 在 最 后 就 借 
着 “实现 ”这 个 稍微 复杂 的 功能 来 学 习 一 下 Git 分 文 的 变 基 操 作 ， 有 具体 操作 
过 程 如 下 。 


(1) 进入 user2 的 工作 区 ， 并 切换 到 user2/i18n 分 文 。 





$ cd /path/to/user2/workspace/hello-world/ 
$ git checkout user2/ii8n 
Switched to branch 'user2/i1i8n' 





(2) 使 用 gettext 为 软件 添加 多 语言 支持 。 您 可 以 尝试 实现 该 功 
能 。 不 过 在 hello-world 中 已 经 保存 了 一 份 实现 该 功能 的 代码 〈 见 里 程 碑 
jx/v1.0-il8n) ， 可 以 直接 拿 过 来 用 。 








(3) 里程碑 jx/v1.0-il8n 最 后 的 两 个 提交 实现 了 多 语言 文 持 功 能 。 





$ git log --oneline -2 --stat jx/v1.0-ii8n 

ade873c Translate for Chinese. 
src/locale/zh_CN/LC_ MESSAGES/helloworld.po | 30 + 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 二 十 =- ----- 
1 files changed, 23 insertions(+), 7 deletions(-) 

0831248 Add I18N support. 


src/Makefile | 21 十 十 十 十 十 十 十 十 十 十 十 - 
src/locale/helloworld.pot | 46 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 
src/locale/zh_CN/LC_MESSAGES/helloworld.po | 46 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 
src/main.c | 18 十 + 十 十 十 十 二 十 - - 


4 files changed， 125 insertions(+), 6 deletions(-) 


一 


(4) 可 以 通过 拣选 命令 将 这 两 个 提交 拣选 到 user2/il18n 分 文中 ， 相 
当 于 在 分 文 user2/i18n 中 实现 了 多 语言 支持 的 开发 。 





$ git cherry-pick jx/v1i.0-i1i8n~1 


$ git cherry-pick jx/v1i.0-ii8n 





(5) 看 看 当前 分 文 拒 选 后 的 日 志 。 





$ git lo0g --oneline -2 
7acb3e8 Translate for Chinese. 
90d873b Add I18N support. 





(6) 为 了 测试 刚刚 “开发 ”完成 的 多 语言 文 持 功能 ， 先 对 源码 执行 





$ cd src 

$ make 

version.h.in => version.h 
cc -C -0 main.o main.c 


msgfmt -0 locale/zh_CN/LC_ MESSAGES/helloworld.mo 
locale/zh_CN/LC_MESSAGES/helloworld.po 
cc -0 hello main.o 





(7) 碍 看 帮助 信息 ， 会 发 现 帮助 信息 已 经 本 地 化 。 


注意 : 帮助 信息 中 仍然 有 文字 错误 ， --helpt 吴 写 为 - help 。 





$ ./hello --help 

Hello world 示例 v1.0-2-g7acb3e8 

版 权 所 有 蒋 讲 <jiangxin AT ossxp DOT com>， 2009 
用 法 : 




















hello 

世界 你 好 。 
hello <username> 
向 用 户 问 您 好 。 




















hello -h, -help 
显示 本 帮助 页 。 





(8) 不 带 用 户 名 运行 hallo， 也 会 输出 中 文 。 





$ ./hello 
世界 你 好 。 
(version: v1.0-2-g7acb3e8) 








(9) 带 用 户 名 运行 hello， 会 向 用 户 问 候 。 


注意 : 程序 仍然 存在 只 显示 部 分 用 户 名 的 问题 。 





$ ./hello Jiang Xin 
您 好 ， Jiang. 
(version: v1.0-2-g7acb3e8) 





(10) 推送 分 支 user2/i18n 到 远程 共享 服务 器 。 





推送 该 特性 分 文 的 目的 并 非 是 与 他 人 在 此 分 文 上 协同 工作 ， 主 要 是 
为 了 进行 数据 备份 。 





$ git push origin user2/ii8n 
Counting objects: 21, done. 
Delta compression using up to 2 threads. 
Compressing objects: 100% (13/13), done. 
Writing objects: 100% (17/17), 2.91 KiB, done. 
Total 17 (delta 6), reused 1 (delta 0) 
Unpacking objects: 100% (17/17), done. 
To file:///path/to/repos/hello-world.git 

* [new branch] USer2/i18n -> user2/ii8n 





18.6.2 “分支 user2/i18n 变 基 








在 测试 刚刚 完成 的 具有 多 语种 支持 功能 的 hello-world 时 ， 之 前 改正 
的 两 个 Bug 又 重 现 了 。 这 并 不 奇怪 ， 因 为 分 文 user2/i18n 基 于 master 分 文 
创建 的 时 候 ， 这 两 个 Bug 还 没有 发 现 呢 ， 更 不 要 说 改正 了 。 





在 最 早 刚 刚 创 建 user2/i18n 分 支 时 ， 版 本 库 的 结构 非常 简单 ， 如 图 
18-6 所 示 。 






图 18-6 ”分 支 user2/i18n 创 建 初始 版 本 库 的 分 支 状态 





但 是 当前 master 分 文中 不 但 包含 了 对 两 个 Bug 的 修正 ， 还 包含 了 开 
发 者 user1 调 用 getopt 对 命令 行 参数 解析 进行 的 代码 重 构 。 图 18-7 显 示 的 
是 当前 版 本 库 master 分 支 和 user2/i18n 分 支 的 关系 图 。 





initial : : bugfix#2 : 


天 
be ” 









图 18-7 ”当前 版 本 库 分 支 示意 图 
开发 者 user2 要 将 分 支 user2/il18n 中 的 提交 合并 到 主线 master 中 ， 可 以 
采用 上 一 节 介 绍 的 分 文 合 并 操作 。 如 果 执 行 分 支 合 并 操作 ， 版 本 库 的 状 


态 将 会 如 图 18-8 所 示 : 


了 | 志 本 下 利生 虱 天 要 本 要 十 末 惠 。 
本 % . 和 





图 18-8 ”使 用 分 支 合并 时 版 本 库 的 分 支 状态 





这 样 操 作 有 利 有 次。 有 利 的 一 面 是 开发 者 在 user2/i18n 分 支 中 的 提 
交 不 会 发 生 改变 ， 这 一 点 对 于 提交 已 经 被 他 人 共享 时 很 重要 。 再 有 因为 
user2/i18n 分 文 是 基于 v1.0 创 建 的 ， 这 样 可 以 很 容易 将 多 语言 支持 功能 添 
加 到 1.0 版 本 的 hello-world 中 。 不 过 这 些 对 于 本 项 目 来 说 都 不 重要 。 至 于 
不 利 的 一 面 ， 就 是 这 样 的 合并 操作 会 产生 三 个 提交 (包括 一 个 合并 提 
交 ) ， 对 于 要 对 提交 进行 审核 的 项 目 团 队 来 说 增加 了 代码 审核 的 负担 。 
因此 很 多 项 目 在 特性 分 支 合 并 到 开发 主线 的 时 候 ， 都 不 推荐 使 用 合并 操 
作 ， 而 是 使 用 变 基 操 作 。 如 果 执 行 变 基 操 作 ， 版 本 库 相 关 分 文 的 关系 图 
就 如 图 18-9 所 示 。 
































图 18-9 ”使 用 变 基 操作 版 本 库 的 分 支 状态 


很 显然 ， 采 用 变 基 操 作 的 分 文 天 系 图 要 比 采 用 合并 操作 的 简单 多 
了 ， 看 起 来 更 像 是 集中 式 版 本 控制 系统 特有 的 顺序 提交 。 因 为 减少 了 一 
个 提交 ， 也 会 减轻 代码 审核 的 负担 。 





下 面 开 发 者 user2 束 通过 变 基 操 作 将 特性 分 文 user2/iL8n 合 并 到 主 
线 ， 有 具体 操作 过 程 如 下 。 


(1) 首先 确保 开发 者 user2 的 工作 区 位 于 分 支 user2/il8n 上 。 





$ cd /path/to/user2/workspace/hello-world/ 
$ git checkout user2/i18n 





(2) 执行 变 基 操作 。 





$ git rebase master 


First, rewinding head to replay your work on top of it... 

Applying: Add I18N support. 

Using index info to reconstruct a base tree... 

Falling back to patching base and 3-way merge... 

Auto-merging src/main.c 

CONFLICT (content): Merge conflict in src/main.c 

Failed to merge in the changes. 

Patch failed at 0001 Add I18N support. 

When you have resolved this problem run "git rebase --continue". 

If you would prefer to Skip this patch, instead run "git rebase --skip". 
To restore the original branch and stop rebasing run "git rebase --abort". 








变 基 巡 到 了 冲突 ， 看 来 这 回 的 麻烦 可 不 小 。 冲 突 是 在 合并 
user2/i18n 分 支 中 的 提交 “Add I18N support" 时 遇 到 的 。 首 先 回顾 一 下 变 
基 的 原理 ， 参 见 第 2 篇 “第 12 章 改变 历史 ”的 相关 章节 。 对 于 本 例 ， 在 进 
行 变 基 操 作 时 会 先 切换 到 user2/i18n 分 支 ， 并 强制 重 置 到 master 分 支 所 指 
回 的 提交 。 然 后 再 将 原 user2/i18n 分 文 的 提交 一 一 拣选 到 新 的 user2/i18n 
分 广 上 。 运 行 下 面 的 命令 可 以 查看 可 能 导致 冲突 的 提交 列表 。 








$ git rev-list --pretty=oneline user2/ii8n^...master 
d81896e60673771ef1873b27a33f52df75f70515 Fix typo: -help to --help. 
10765a7ef46981a73d578466669f6e17b73ac7e3 Bugfix: allow spaces in username. 
90d873bb93cd7577b7638f1f391bd2ece3141b7a Add I18N support. 
0881ca3f62ddadcddec08bd9f2f529a44d17cfbf Refactor: use getopt_ long for arguments par 





刚刚 发 生 的 冲突 是 在 拣选 提交 *Add I18N suppport” 时 出 现 的 ， 所 以 
在 冲突 文件 中 标识 为 他 人 版 本 的 是 user2 添 加 多 语种 支持 功能 的 提交 ， 而 
冲突 文件 中 标识 为 自己 版 本 的 是 修正 两 个 Bug 的 提交 及 开发 者 userl 提 交 
的 重 构 命 令 行 参 数 解析 的 提交 。 下 面 的 两 个 表格 〈 表 18-2 和 表 18-3) 是 
文件 src/main.c 发 生 冲 突 的 两 个 主要 区 域 ， 表 格 的 左 侧 一 列 是 冲突 文件 中 
的 内 容 ， 石 侧 一 列 则 是 冲突 解决 后 的 内 容 。 为 了 方便 对 照 进行 了 适当 排 
版 。 

















变 基 冲突 区 域 一 内 容 (文件 src/main.c) 


冲突 解决 后 的 内 容 对 照 





12 int usage(int code) 
13 { 
14 printf( ("Hello world example %s\n" 


15 "Copyright Jiang Xin <jiangxin AT ossxp ...\n" 
16 ny" 

17 "Usage:\n" 

18 " hello\n" 

19 say hello to the world.\n\n" 

20 " hello <username>\n" 

21 | say hi to the user.\n\n" 

22 <<<<<<< HEAD 

23 " hello -h, --help\n" 

24 this help screen.\m\n". VERSION): 
25 | merged common ancestors 

26 " hello -h. -help\n" 

27 this help screen.\n\n". VERSION): 
Ds 

29 " hello -h. -help\n" 

30 和 this help screen.\n\n"), _ VERSION): 


1 >>>>>>> Add II18N support. 
32 return code: 
33 


表 18-3 


变 基 ，; 


Ar 


入 





区 


12 int usage(int code) 


13{ 
14 


24 
25} 


域 二 解决 


printf(_("Hello world example %s\n" 
"Copyright Jiang Xin <jiangxin AT ossxp ...\n 
np" 
"Usage:\n" 
" hello\n" 
say hello to the world.\n\n" 
hello <username>\n" 
say hi to the user.\n\n" 


" hello -h., --help\n" 
站 this help screen.\m\n"). _VERSION): 


return code: 


前 后 





变 基 冲 突 区 域 二 内 容 (文件 src/main.c ) 


38 <<<<<<< HEAD 


39 
40 
41 


45 


nt ec; 
char **p = NULL; 


while (1) { 


int option index = 0: 

static struct option long_options[] = { 
{"help" 0;0 1}, 
{0. 0, 0, 0} 

入 


c= getopt long(argc, argv, "h", 
long_options. &option index): 
1f(e—=—1) 
break: 


switch (c) { 
case h'; 

return usage(0): 
default: 





int c: 
char **p = NULL; 


setlocale( LC ALL,.""); 
bindtextdomain("'helloworld"."locale"); 
textdomain("'helloworld"); 


while (1) { 
int option index = 0: 
static struct option long options[]={ 
"help",0,,0, hb'}; 
{0, 0, 0, 0} 
站 


c= getopt_ long(argc, argv, "h", 
long_options, &option index); 
if (c==—1) 
break: 


Switch (c) { 
case 'h': 

return usage(0): 
default: 





变 基 冲突 区 域 二 内 容 (文件 src/main.c ) 


58 return usage( 1); 

59 } 

60 } 

61 

62 if(optind < argc) { 

03 p= &argv[optind]; 

64 } 

65 

66 if(p== NULL||*p== NULL){ 
67 printf ("Hello world.\n"'); 

68 ll| merged common ancestors 

69 if(arpgc== 1)t{ 

70 printf ("Hello world.\n"); 

71 }elseif( stremp(argv[1],"-h")==0|| 


72 stremp(argv[1],"--help") == 0 ) { 
73 return usage(0); 
74 ======= 


13 setlocale( LC ALL,"™); 
76 bindtextdomain("helloworld","locale"); 
77 textdomain("helloworld"); 


79 if(argc== 1)t{ 
80 printf (_("Hello world.\n") ); 
81 }elseif( stremp(argv[1],"-h")== 0 


82 stremp(argv[1],"--help") =—= 0 ) { 
83 return usage(0); 

84 >>>>>>> Add I18N support. 

85 }elsef{ 

86 <<<<<<< HEAD 

87 printf ("Hi,"); 

88 dof 

89 printf (" %s", *p); 


90 } while (*(++p)); 
91 printf (".\n"); 


92 |lmerged common ancestors 
93 printf ("Hi, %s.\n", argv[1]); 
94 一 = 一 一 = 


95 printf (_("Hi, %s.\n"), argv[1]); 
96 >>>>>>> Add I18N support. 
97 } 





站 突 解决 后 的 内 容 对 照 


return usage( 1); 
} 
} 


if (optind < argc) { 
p= &argv[optind]; 
} 


if(p== NULL | *p.=—= NULL) 并 
printf (_ ("Hello world.\n") ); 


} else { 


printf (_ ("Hi,")); 
do { 

printf (" %s", *p); 
} while (*(++p)); 
printf (".\n"); 


将 完成 冲突 解决 的 文件 src/main.c 加 入 暂 存 区 。 


$ git add -u 


查看 工作 区 状态 。 








| 


$ git status 
# Not currently on any branch. 
# Changes to be committed: 


# (use "git reset HEAD <file>..." to unstage) 

# 

# modified: src/Makefile 

# new file: src/locale/helloworld.pot 

# new file: src/locale/zh_CN/LC MESSAGES/helloworld.po 
# modified: src/main.c 

# 





现在 不 要 执行 提交 ， 而 是 继续 变 基 操 作 。 变 基 操 作 会 自动 完成 对 冲 
突 解决 的 提交 ， 并 对 分 文中 的 其 他 提交 继续 执行 变 基 ， 直 至 全 部 完成 。 





$ git rebase --continue 
Applying: Add I18N support. 
Applying: Translate for Chinese. 











图 18-10 显 示 了 版 本 库 执行 完 变 基 后 的 状态 。 


nN 


. . 
TT 






图 18-10 变 基 操作 完成 后 版 本 库 的 分 支 状态 


现在 需要 将 user2/i18n 分 支 的 提交 合并 到 主线 master 中 。 实 际 上 不 需 
要 在 master 分 文 上 再 执行 索 琐 的 合并 操作 ， 而 是 可 以 直接 用 推送 操作 
一 一 用 本 地 的 user2/i18n 分 支 直接 更 新 远程 版 本 库 的 master 分 支 。 











$ git push origin user2/ili8n:master 

Counting objects: 21, done. 

Delta compression using up to 2 threads. 
Compressing objects: 100% (13/13), done. 
Writing objects: 100% (17/17), 2.91 KiB, done. 
Total 17 (delta 6), reused 1 (delta 0) 
Unpacking objects: 100% (17/17), done. 

To file:///path/to/repos/hello-world.git 





仔细 看 看 上 面 运行 的 git push 命 令 ， 终 于 看 到 了 引用 表达 式 中 冒号 前 
后 使 用 了 不 同名 字 的 引用 。 含 义 是 用 本 地 的 user2/i18n 引 用 的 内 容 〈 提 
交 ID) 更 新 远程 共享 版 本 库 的 master 引 用 内 容 (提交 ID) 。 


执行 拉 回 操作 ， 可 以 发 现 远程 共享 版 本 库 的 master 分 文 的 确 被 更 新 
了 。 通 过 拉 回 操作 本 地 的 master 分 支 也 随 之 更 新 。 





(1) 切换 到 master 分 支 ， 会 从 提示 信息 中 看 到 本 地 master 分 支 沙 后 


远程 共 译 版 本 库 master 分 文 两 个 提交。 








$ git checkout master 
Switched to branch 'master' 
Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded. 





(2) 执行 拉 回 操作 ， 将 本 地 master 分 支 同 步 到 和 远程 共享 版 本 库 相 
同 的 状态 。 





$ git pull 
Updating d81896e..c4acab2 
Fast-forward 


src/Makefile | 仿生 让 半生 让 站 半音 计 = 
src/locale/helloworld.pot | 46 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 
src/locale/zh_CN/LC_MESSAGES/helloworld.po | 62 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 
src/main.c | 18 上 ++++++- - 


4 files changed, 141 insertions(+), 6 deletions(-) 
create mode 100644 src/locale/helloworld.pot 
create mode 100644 src/locale/zh_CN/LC_ MESSAGES/helloworld.po 





特性 分 文 user2/i18n 也 完成 了 历史 使 傅 ， 可 以 删除 了 。 因 为 之 前 
user2/i18n 己 经 推送 到 远程 共享 版 本 库 ， 如 果 想 要 删除 分 支 不 要 筷 了 也 
将 远程 分 支 同 时 删除 。 


(1) 删除 本 地 版 本 库 的 user2/i18n 分 支 。 





$ git branch -d user2/ii8n 
Deleted branch user2/ii8n (was c4acab2). 





(2) 删除 远程 共享 版 本 库 的 user2/i18n 分 支 。 





$ git push origin :user2/ii8n 
To file:///path/to/repos/hello-world.git 
- [deleted] USer2/i18n 





补充 “实际 上 变 基 之 后 uset2/i18n 分 支 的 本 地 化 模板 文件 
(helloworld.pot) 和 汉化 文件 (helloworld.po) 都 需要 做 出 相应 更 新 ， 
则 hello-world 的 一 些 输 出 不 能 进行 本 地 化 。 


更 新 模板 需要 删除 文件 helloworld.pot， 再 执行 命令 make po。 


重新 翻译 中 文本 地 化 文件 ， 可 以 使 用 工具 lokalize 或 kbabel。 


具体 的 操作 过 程 就 不 再 玖 述 了 站 。 


[1 在 本 篇 第 20 章 “20.3.1 StGit” 一 节 会 弥补 这 一 遗憾 ， 完 善 Hello Word 


的 本 地 化 。 


第 19 章 ”远程 版 本 库 





Git 作 为 分 布 式 版 本 库 控制 系统 ， 每 个 人 都 是 本 地 版 本 库 的 主人 ， 
可 以 在 本 地 的 版 本 库 中 随心 所 欲 地 创建 分 支 和 里 程 碑 。 当 需要 多 人 协作 
时 ， 问 题 就 出 现 了 : 


如 何 避 免 因为 用 户 把 所 有 的 本 地 分 支 都 推送 到 共享 版 本 库 ， 从 而 
造成 共享 版 本 库 上 分 支 的 混乱 ? 


. 如 何 避 免 不 同 用 户 针对 不 同 特性 开发 创建 了 相同 名 字 的 分 支 而 造 
成 分 支 名 称 的 冲突 ? 


. 如 何 避 免 用 户 随 意 在 共享 版 本 库 中 创建 里 程 碑 而 导致 里 程 碑 名 称 
上 的 混乱 和 冲突 ? 


当 用 户 向 共享 版 本 库 及 其 他 版 本 库 推 送 时 ， 每 次 都 需要 输入 长 长 
的 版 本 库 URL， 太 不 方便 了 。 


* 当 用 户 需 要 经 常 从 多 个 不 同 的 他 人 版 本 库 中 获取 提交 时 ， 有 没有 
办 法 不 要 总 是 输入 长 长 的 版 本 库 URL? 


` 如 果 不 带 任何 其 他 参数 执行 git fetch、git pull 和 git push 到 底 是 和 哪 
个 远程 版 本 库 及 哪个 分 支 进 行 交互 ? 





本 章 介 绍 的 git remote 命 令 就 是 用 于 实现 对 远程 版 本 库 的 便捷 访问 ， 
建立 远程 分 文 和 本 地 分 文 的 对 应 ， 使 得 git fetch、git pul 和 git push 能 够 
更 为 便捷 地 进行 操作 。 


19.1 远程 分 支 


上 一 半 介 绍 Git 分 文 的 时 候 ， 每 一 个 版 本 库 最 多 只 和 一 个 上 游 版 本 
库 《〈 远 程 共 孚 版 本 库 ) 进行 交 互 ， 实 际 上 Git 允 许 一 个 版 本 库 和 任意 多 
的 版 本 库 进行 交互 。 痛 先 执 行 下 面 的 命令 ， 基 于 hello-world.git 版 本 库 再 
创建 几 个 新 的 版 本 库 。 





$ cd /path/to/repos/ 

$ git clone --bare hello-world.git hello-user1.git 
Cloning into bare repository hello-useri1.git... 
done. 

$ git clone --bare hello-world.git hello-user2.git 
Cloning into bare repository hello-user2.git... 
done. 





现在 有 了 三 个 共享 版 本 库 : hello-world.git、hello-user1.git 和 hello- 
user2.git。 现 在 有 一 个 疑问 ， 如 果 一 个 本 地 版 本 库 需 要 和 上 面 三 个 版 本 
库 进 行 互 操作 ， 三 个 共享 版 本 库 都 存在 一 个 master 分 支 ， 会 不 会 互相 干 
扰 、 冲 突 或 覆盖 呢 ? 








先 来 看 看 hello-world 远 程 共享 版 本 库 中 包含 的 分 支 有 哪些 : 





$ git ls-remote --heads file:///path/to/repos/hello-world.git 


8cffe5f135821e716117ee59bdd53139473bd1d8 refs/heads/hello-1.x 
bb4fef88fee435bfac04b8389cf193d9c04105a6 refs/heads/helper/master 
cf71ae3515e36a59c7f98b9db825fdof2a318350 refs/heads/helper/vi1.x 
c4acab26ff1c1125f5e585ffa8284d27f8ceea55 refs/heads/master 








原来 远程 共享 版 本 库 中 有 四 个 分 文 ， 其 中 hello-1.x 分 文 是 开发 着 





user1 创 建 的 。 现 在 重新 克隆 该 版 本 库 ， 如 下 : 





$ cd /path/to/my/workspace/ 
$ git clone file:///path/to/repos/hello-world.git 


$ cd /path/to/my/workspace/hello-world 





执行 git branch 命 令 检查 分 文 ， 会 吃惊 地 看 到 只 有 一 个 分 文 master。 





$ git branch 
* master 





那么 远程 版 本 库 中 的 其 他 分 文 哪 里 去 了 ? 为 什么 本 地 只 有 一 个 分 文 
呢 ? 执行 git show-ref 命 令 可 以 看 到 全 部 的 本 地 引用 。 





$ git show-ref 

c4acab26ff1c1125f5e585ffa8284d27f8ceea55 refs/heads/master 
c4acab26ff1c1125f5e585ffa8284d27f8ceea55 refs/remotes/origin/HEAD 
8cffe5f135821e716117ee59bdd53139473bd1d8 refs/remotes/origin/hello-1.x 
bb4fef88fee435bfac04b8389cf193d9c04105a6 refs/remotes/origin/helper/master 
cf71ae3515e36a59c7f98b9db825fdof2a318350 refs/remotes/origin/helper/vi1.x 
c4acab26ff1c1125f5e585ffa8284d27f8ceea55 refs/remotes/origin/master 
3171561b2c9c57024f7d748ala5cfd755a26054a refs/tags/jx/v1.0 
aaff5676a7c3ae7712af61dfb9ba05618c74bbab refs/tags/jx/v1.0-i1i8n 
e153f83ee75d25408f7e2fd8236ab18coabfgoec4 refs/tags/jx/v1. 
83f59c7a88c04ceb703e490a86dde9af41de8bcb refs/tags/jx/v1. 
1581768ec71166d540e662d90290cb6f82a43bb0 refs/tags/jx/v1. 
ccca267c98380ea7fffb241f103d1ie6f34d8bc01 refs/tags/jx/v2. 
8a5b9934aacdebb72341dcadbb2650cf626d83da refs/tags/jx/v2. 
89b74222363e8cbdf91aab30d005e697196bd964 refs/tags/jx/v2. 
Ob4ec63aea44b96d498528dcf3e72e1255d79440 refs/tags/jx/v2. 
60a2f4f31e5dddd777c6ad37388fe6e5520734cb refs/tags/mytag 
5dc2fc52f2dcb84987f511481cc6b71ec1b381f7 refs/tags/mytag3 
51713af444266d56821fe3302ab44352b8c3eb71 refs/tags/v1.0 
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从 git show-ref 的 输出 中 发 现 了 几 个 不 寻常 的 引用 ， 这 些 引用 以 
refs/remotes/origin/ 为 前 级 ， 并 且 名 称 和 远程 版 本 库 的 分 支 名 一 一 对 应 。 
这 些 引 用 实际 上 束 是 从 远程 版 本 库 的 分 文 复 制 过 来 的 ， 称 为 远程 分 文 。 


Git 的 git branch 命 令 也 能 够 查看 这 些 远程 分 文 ， 不 过 要 加 上 “-r” 参 


数 : 





$ git branch -r 
origin/HEAD -> origin/master 
origin/hello-1.x 
origin/helper/master 
origin/helper/vi.x 
origin/master 





Git 这 样 的 设计 是 非常 巧妙 的 ， 在 从 远程 版 本 库 执行 获取 操作 时 ， 
不 是 把 远程 版 本 库 的 分 支 原 封 不 动 地 复制 到 本 地 版 本 库 的 分 支 中 ， 而 是 
复制 到 另外 的 命名 空间 。 如 在 克隆 一 个 版 本 库 时 ， 会 将 远程 分 支 都 复制 
到 目录 .git/refs/remotes/origin/ 下 。 这 样 从 不 同 的 远程 版 本 库 执行 获取 操 
作 ， 因 为 通过 命名 空间 的 相互 隔离 ， 所 以 就 避免 了 在 本 地 的 相互 履 盖 。 


那么 克隆 操作 产生 的 远程 分 支 为 什么 都 有 一 个 名 为 “origin/” 的 前 级 
呢 ? 奥秘 就 在 配置 文件 .giVconfig 中 。 下 面 的 几 行内 容 出 自 该 配置 文件 ， 
为 了 说 明 方 便 显 示 了 行 号 。 




















6 [remote "origin"] 
7 fetch = +refs/heads/*:refs/remotes/origin/* 
8 url = file:///path/to/repos/hello-world.git 





这 个 小 节 可 以 称 为 [remote] 小 节 ， 该 小 节 以 origin 为 名 注册 了 一 个 远 
程 版 本 库 。 该 版 本 库 的 URL 地 址 由 第 8 行 给 出 ， 会 发 现 这 个 URL 地 址 就 
是 执行 git clone 命 令 时 所 用 的 地 址 。 最 具 魔 法 的 配置 是 第 7 行 ， 这 一 行 设 
置 了 执行 git fetch origin 操 作 时 使 用 的 默认 引用 表达 式 : 


“该 引用 表达 式 以 加 号 〈+) 开头 ， 含 义 是 强制 进行 引用 的 替换 ， 
即使 即将 进行 的 替换 是 非 快 进 式 的 。 


` 引用 表达 式 中 使 用 了 通配符 ， 冒 号 前 面 的 含有 通配符 的 引用 指 的 
是 远程 版 本 库 的 所 有 分 支 ， 冒 号 后 面 的 引用 含义 是 复制 到 本 地 的 远程 分 
支 目录 中 。 


正 因 为 有 了 上 面 的 [remote] 配 置 小 节 ， 当 执行 git fetch origin 操 作 
时 ， 就 相当 于 执行 了 下 面 的 命令 ， 将 远程 版 本 库 的 所 有 分 文 复制 为 本 地 
的 远程 分 支 。 











git fetch origin +refs/heads/*:refs/remotes/origin/* 





远程 分 文 不 是 真正 意义 上 的 分 文 ， 是 类 似 于 里 程 碑 一 样 的 引用 。 如 
打针 对 远程 分 文 执行 检 出 命令 ， 会 看 到 大 段 的 错误 警告 。 





$ git checkout origin/hello-1.x 

Note: checking out 'origin/hello-1.x'. 

You are in 'detached HEAD' state. You can look around, make experimental 

changes and commit them, and you can discard any commits you make in this 

state without impacting any branches by performing another checkout. 

If you want to create a new branch to retain commits you create, you may 

do so (now or later) by using -b with the checkout command again. Example: 
git checkout -b new_branch_name 

HEAD is now at 8cffe5sf... Merge branch 'hello-1.x' of 

file:///path/to/repos/hello-world into hello-1.x 





上 面 大 段 的 错误 信息 实际 上 告诉 我 们 一 件 事 ， 远 程 分 文 类 似 于 里 程 
盾 ， 如 果 检 出 就 会 使 得 头 指针 HEAD 处 于 分 离 头 指针 状态 。 实 际 上 除了 
以 refs/heads 为 前 绥 的 引用 之 外 ， 如 果 检 出 任何 其 他 引用 ， 都 将 使 工作 区 





处 于 分 离 头 指针 状态 。 如 果 对 远程 分 文 进 行 修改 就 需要 创建 新 的 本 地 分 
es 


19.2 ”分支 追 


为 了 能 够 在 远程 分 支 refs/remotes/origin/hello-1.x 上 进行 工作 ， 需 要 
基于 该 远程 分 支 创 建 本 地 分 支 。 远 程 分 支 可 以 使 用 简写 origin/hello- 
1.X。 如 果 Git 的 版 本 是 1.6.6 或 更 新 的 版 本 ， 可 以 使 用 下 面 的 命令 同时 完 
成 分 支 的 创建 和 切换 。 





$ git checkout hello-1.x 
Branch hello-1.x set Up to track remote branch hello-1.x from origin. 
Switched to a new branch 'hello-1.x' 





如 打 Git 的 版 本 比较 老 ， 或 注册 了 多 个 远程 版 本 库 ， 因 此 存在 多 个 
名 为 hello-1.x 的 远程 分 文 ， 就 不 能 使 用 上 面 简 涪 的 分 文 创建 和 切换 命 
令 ， 而 需要 使 用 在 上 一 章 中 学 习 到 的 分 支 创建 命令 ， 显 式 地 从 远程 分 支 
中 创建 本 地 分 文 。 





$ git checkout -b hello-1.x origin/hello-1.x 
Branch hello-1.x set Up to track remote branch hello-1.x from origin. 
Switched to a new branch 'hello-1.x' 





在 上 面 基于 远程 分 文 创 建 本 地 分 支 的 过 程 中 ， 命 令 输出 的 第 一 行 说 
的 是 建立 了 本 地 分 文 和 远程 分 文 的 跟踪 。 和 远程 分 文 建立 跟踪 后 ， 本 地 


` 检查 工作 区 状态 时 ， 会 显示 本 地 分 支 和 被 跟踪 远程 分 支 提交 之 间 


的 关系 。 


. 当 执 行 git pull 命 令 时 ， 会 和 被 跟踪 的 远程 分 支 进 行 合并 (或 者 变 


基 ) ， 如 果 两 者 出 现 版 本 偏离 的 话 。 


当 执 行 git push 命 令 时 ， 会 推送 到 远程 版 本 库 的 同名 分 支 中 。 





下 面 就 在 基于 远程 分 支 创建 的 本 地 跟踪 分 支 中 进行 操作 ， 看 看 本 地 
分 文 是 如 何 与 远程 分 文 建 立 关 联 的 ， 有 具体 操作 过 程 如 下 。 





(1) 先 将 本 地 hello-1.x 分 支 问 后 重 置 两 个 版 本 。 





$ git reset --hard HEADAA 
HEAD is now at ebcf6d6 blank commit for GnuPG-signed tag test. 





(2) 然后 查看 状态 ， 显 示 当 前 分 文 相 比 跟 踩 分 文 落后 了 3 个 版 本 。 





之 所 以 落后 三 个 版 本 而 非 两 个 版 本 是 因为 hello-1.x 的 最 新 提交 是 一 
个 合并 提交 ， 包 含 两 个 父 提交 ， 因 此 上 面 的 重 置 命令 丢弃 掉 了 三 个 所 


x 
Xo 





$ git status 
# On branch hello-1.x 
# Your branch is behind 'origin/hello-1.x' by 3 commits, and can be fast-forwarded. 


## 
nothing to commit (working directory clean) 








(3) 执行 gitpull 命 令 ， 会 目 动 与 跟踪 的 远程 分 文 进行 合并 ， 相 当 
于 找 回 最 新 的 3 个 提交 。 





$ git pull 
Updating ebcf6d6. .8cffesf 
Fast-forward 
src/main.c | 41 十 十 十 十 十 十 十 二 十 - - 
1 files changed, 9 insertions(+), 2 deletions(-) 











但 是 如 果 基 于 本 地 分 文 创 建 另 外 一 个 本 地 分 文 则 没有 分 文 跟踪 的 功 
能 。 下 面 就 从 本 地 的 hello-1.x 分 支 中 创建 hello-jx 分 支 。 


1) 从 hello-1.x 分 文中 创建 新 的 本 地 分 文 hello-jx。 


下 面 的 创建 分 文 操 作 只 有 一 行 输出 ， 看 不 到 分 文 间 建立 跟踪 的 提 


钞 。 





$ git checkout -b hello-jx hello-1.x 
Switched to a new branch 'hello-jx' 





(2) 将 hello-jx 分 支 重 置 。 





$ git reset --hard HEADAA 
HEAD is now at ebcf6d6 blank commit for GnuPG-signed tag test. 





(3) 检查 状态 看 不 到 分 支 间 的 跟踪 信息 。 





$ git status 
# On branch hello-jx 
nothing to commit (working directory clean) 





(4) 执行 git pul 命 令 会 报错 。 





$ git pull 
You asked me to pull without telling me which branch you 


want to merge with， and 'branch.hello-jx.merge' in 
your configuration file does not tell me， either， 
specify which branch you want to use on the command 
try again (e.g. 'git pull <repository> <refspec>'). 
See git-pull(1) for details. 
If you often merge with the same branch, 
use something like the following in your configurat 

[branch "hello-jx"] 

remote = <nickname> 

merge = <remote-ref> 

[remote "<nickname>"] 

url = <url> 

fetch = <refspec> 
See git-config(1) for details. 


Please 


line and 


you may want to 


ion file: 





将 上 面 命令 执行 中 的 错误 信息 翻译 过 来 ， 


束 是 : 






































$ git pull 
您 让 我 执行 拉 回 操作 ， 但 是 没有 告诉 我 您 希望 与 哪个 远程 分 支 进行 合 
而 且 也 没有 通过 配置 'branch.hello-jx.merge' 来 告诉 我 。 


























请 在 命令 行 中 提供 足够 的 参数 ， 如 'git pull <repository> <r 

或 者 如 果 您 ST ， 可 以 和 该 分 支 建立 跟踪 。 在 丁 

中 添加 如 下 配置 信息 
[branch "hello- jx"] 
remote = <nickname> 
merge = <remote-ref> 
[remote "<nickname>"] 
url = <url> 
fetch = <refspec> 







































































efspec>' 。 





b 告 








为 什么 用 同样 方法 建立 的 分 支 hello-1.x 和 
呢 ? 奥秘 就 在 于 从 远程 





hello-jix， 差 距 咋 就 那么 大 


分 文 创 建 本 地 分 文 ， 目 动 建立 了 分 文 间 的 跟踪 ， 





而 从 一 个 本 地 分 支 创 建 男 外 一 个 本 地 分 支 则 没有 。 看 看 配置 文 
件 .git/config 中 是 不 是 专门 为 分 支 hello-1.x 创 建 了 相应 的 配置 信息 ? 











9 [branch "master"] 
10 remote = origin 


11 merge = refs/heads/master 

12 [branch "hello-1.x"] 

13 remote = origin 

14 merge = refs/heads/hello-1.x 


人 | 








其 中 第 9~11 行 是 针对 master 分 支 设 置 的 分 文 间 跟 踪 ， 是 在 版 本 库 克 
隆 的 时 候 目 动 建立 的 。 而 第 12~14 行 是 前 面 基 于 远程 分 支 创 建 本 地 分 文 
时 建立 的 。 至 于 分 文 hello-j 则 没有 建立 相关 的 配置 。 








如 宁 和 希望 在 基于 一 个 本 地 分 文 创建 咏 外 一 个 本 地 分 文 时 也 能 够 使 用 
分 文 间 的 跟 踩 功能， 就 要 在 创建 分 文 时 提供 --track 参 数 。 下 面 实践 一 
下 ， 具 体操 作 过 程 如 下 。 


(1) 删除 之 前 创建 的 hello-jx 分 支 。 





$ git checkout master 

Switched to branch 'master' 

$ git branch -d hello-jx 

Deleted branch hello-jx (was ebcf6d6). 





(2) 使 用 参数 --track 重 新 基于 hello-1.x 创 建 hello-jx 分 文 。 





$ git checkout --track -b hello-jx hello-1.x 
Branch hello-jx set up to track local branch hello-1.x. 
Switched to a new branch 'hello-jx' 











(3) 从 Git 库 的 配置 文件 中 会 看 到 为 hello-jx 分 文 设置 的 跟踪 。 








因为 跟踪 的 是 本 版 本 库 的 本 地 分 文 ， 所 以 第 16 行 设置 的 远程 版 本 库 
的 各 汪 鸭 二 修 扩 :， 





15 [branch "hello-jx"] 
16 remote = ， 
17 merge = refs/heads/hello-1.x 





19.3 ”远程 版 本 库 





名 为 origin 的 远程 版 本 库 是 在 版 本 库 克隆 时 注册 的 ， 那 么 如 何 注册 
新 的 远程 版 本 库 呢 ? 


1. 注 册 远 程 版 本 库 


下 面 将 版 本 库 fle:///path/to/repos/hello-userl.git 以 new-remote 为 名 进 
行 注 册 。 





$ git remote add new-remote file:///path/to/repos/hello-user1.git 





如 果 再 打开 版 本 库 的 配置 文件 .git/config 会 看 到 新 的 配置 。 





12 [remote "new-remote"] 
13 url = file:///path/to/repos/hello-user1.git 
14 fetch = +refs/heads/*:refs/remotes/new-remote/* 





执行 git remote 命 令 ， 可 以 更 为 方便 地 显示 已 经 注册 的 远程 版 本 库 。 





$ git remote -v 

new-remote file:///path/to/repos/hello-user1.git (fetch) 
new-remote file:///path/to/repos/hello-user1.git (push) 
origin file:///path/to/repos/hello-world.git (fetch) 

origin file:///path/to/repos/hello-world.git (push) 





现在 执行 git fetch 并 不 会 从 新 注册 的 new-remote 远 程 版 本 库 中 获取 ， 
因为 当前 分 文 设置 的 默认 远程 版 本 库 为 origin。 要 想 从 new-remote 远 程 版 





本 库 中 获取 ， 需 要 为 git fetch 命 令 增加 一 个 参数 new-remote。 





$ git fetch new-remote 
From file:///path/to/repos/hello-user1 


* [new branch] hello-1.x -> new-remote/hello-1.x 

* [new branch] helper/master -> new-remote/helper/master 
* [new branch] helper/vi.x -> new-remote/helper/vi1.x 

* [new branch] master -> new-remote/master 





从 上 面 的 命令 输出 中 可 以 看 出 ， 远 程 版 本 库 的 分 支 复 制 到 本 地 版 本 
库 前 缀 为 new-remote 的 远程 分 支 中 去 了 。 用 git branch-r 命 令 可 以 看 到 新 


增 了 几 个 远程 分 文 。 





$ git branch -r 
new-remote/hello-1.x 
new-remote/helper/master 
new-remote/helper/vi.x 
new-remote/master 
origin/HEAD -> origin/master 
origin/hello-1.x 
origin/helper/master 
origin/helper/vi1.x 
origin/master 





2. 更 改 远程 版 本 库 的 地 址 


如 果 远 程 版 本 库 的 URL 地 址 改变 ， 需 要 和 更换， 该 如 何 处 理 呢 ? 手工 
修改 .git/config 文 件 是 一 种 方法 ， 用 git config 命 令 进 行 更 改 是 第 二 种 方 
法 ， 还 有 一 种 方法 是 用 git remote 命 令 ， 如 下: 











$ git remote set-url new-remote file:///path/to/repos/hello-user2.git 





可 以 看 到 注册 的 远程 版 本 库 的 URL 地 址 已 经 更 改 。 





$ git remote -V 

new-remote file:///path/to/repos/hello-user2.git (fetch) 
new-remote file:///path/to/repos/hello-user2.git (push) 
origin file:///path/to/repos/hello-world.git (fetch) 

origin file:///path/to/repos/hello-world.git (push) 








从 上 面 的 输出 中 可 以 发 现 每 一 个 远程 版 本 库 都 显示 两 个 URL 地 址 ， 
分 别 是 执行 git fetch 和 git push 命 令 时 用 到 的 URL 地 址 。 既 然 有 两 个 地 
址 ， 就 意味 着 这 两 个 地 址 可 以 不 同 ， 用 下 面 的 命令 可 以 为 推送 操作 设置 
单独 的 URL 地 址 。 





$ git remote set-url --push new-remote /path/to/repos/hello-user2.git 
$ git remote -v 

new-remote file:///path/to/repos/hello-user2.git (fetch) 
new-remote /path/to/repos/hello-user2.git (push ) 

origin file:///path/to/repos/hello-world.git (fetch) 

origin file:///path/to/repos/hello-world.git (push) 





当 单 独 为 推送 设置 了 URL 后 ， 配 置 文件 .git/config 的 对 应 [remote] 小 
节 也 会 增加 一 条 新 的 名 为 pushurl 的 配置 。 如 下 : 





12 [remote "new-remote"] 

13 url = file:///path/to/repos/hello-user2.git 

14 fetch = +refs/heads/*:refs/remotes/new-remote/* 
15 pushurl = /path/to/repos/hello-user2.git 





3. 更 改 远程 版 本 库 的 名 称 





如 果 对 远程 版 本 库 的 注册 名 称 不 满意 ， 也 可 以 进行 修改 。 例 如 将 
new-remote 名 称 修改 为 user2， 使 用 下 面 的 命 





$ git remote rename new-remote User2 





完成 改名 后 ， 不 但 远程 版 本 库 的 注册 名 称 更 改过 来 了 ， 就 连 远 程 分 
文 的 名 称 都 会 自动 进行 相应 的 更 改 。 可 以 通过 执行 git remote 和 git 
branch-r 命 令 查 看 。 








$ git remote 

origin 

user2 

$ git branch -r 
origin/HEAD -> origin/master 
origin/hello-1.x 
origin/helper/master 
origin/helper/vi1.x 
origin/master 
user2/hello-1.x 
user2/helper/master 
user2/helper/vi.x 
user2/master 





4. 远 程 版 本 库 更 新 











当 注 册 了 多 个 远程 版 本 库 并 希望 获取 所 有 远程 版 本 库 的 更 新 时 ， 
Git 提 供 了 一 个 简单 的 命令 。 





$ git remote update 
Fetching origin 
Fetching user2 





如 果 某 个 远程 版 本 库 不 想 在 执行 git remote update 时 获得 更 新 ， 可 以 
通过 参数 关闭 自动 更 新 。 例 如 下 面 的 命令 关闭 远程 版 本 库 user2 的 自动 更 
新 。 





$ git config remote.user2.skipDefaultUpdate true 
$ git remote update 
Fetching origin 





5. 删 除 远 程 版 本 库 


如 果 想 要 删除 注册 的 远程 版 本 库 ， 用 git remote 的 rm 子 命令 可 以 实 
现 。 例 如 删除 注册 的 user2 版 本 库 。 


$ git remote rm user2 





19.4 PUSH 和 PULL 操 作 与 远程 版 本 库 


Git 分 文 一 章 已 经 介绍 过 对 于 新 建立 的 本 地 分 文 〈 没 有 建立 和 远程 
分 六 的 退 踪 〉， 执 行 git push 命 令 是 不 会 被 推送 到 远程 版 本 库 中 的 ， 这 样 
的 设置 是 非常 安全 的 ， 避 免 了 因为 误 操 作 将 本 地 分 文 创建 到 远程 版 本 库 
中 。 当 不 带 任何 参数 执行 git push 命 令 时 ， 实 际 的 执行 过 程 是 : 





. 如 果 为 当前 分 支 设置 了 ， 即 由 配置 btanch..femote 给 出 了 远程 版 本 
库 代 号 ， 则 不 带 参 数 执行 git push 相 当 于 执行 了 git push。 


.如果 没 有 为 当前 分 支 设置 ， 则 不 带 参 数 执行 gt push 相 当 于 执行 了 
agit push otipgin。 


. 要 推送 的 远程 版 本 库 的 URL 地 址 由 remote..pushutl 给 出 。 如 果 没 有 
配置 ， 则 使 用 remote..utl 配 置 的 URL 地 址 。 


如 果 为 注册 的 远程 版 本 库 设 置 了 push 参 数 ， 即 通过 remote..push 配 
置 了 一 个 引用 表达 式 ， 则 使 用 该 引用 表达 式 执 行 推送 。 


. 否则 使 用 “:” 作 为 引用 表达 式 。 该 表达 式 的 含义 是 同名 分 支 推 
送 ， 即 对 所 有 在 远程 版 本 库 中 有 同名 分 支 的 本 地 分 支 执行 推送 。 


这 也 就 是 为 什么 在 一 个 本 地 新 建 分 文中 执行 git push 推 送 操作 不 会 推 








送 也 不 会 报错 的 原因 ， 因 为 远程 不 存在 同名 分 文 ， 所 以 根本 就 没有 对 该 
分 文 执行 推送 。 而 如 果 本 地 其 他 分 文 在 远程 版 本 库 有 同名 分 文 且 本 地 包 
含 更 新 的 话 ， 会 对 这 些 分 文 进 行 推送 。 





在 Git 分 支 一 章 中 就 已 经 知道 ， 如 果 需 要 在 远程 版 本 库 中 创建 分 
支 ， 则 执行 命令 : git push<remote><new_branch>。 即 通过 将 本 地 分 支 推 
送 到 远程 版 本 库 的 方式 在 远程 版 本 库 中 创建 分 支 。 但 是 在 接 下 来 的 使 用 
中 会 遇 到 麻烦 :不 能 执行 git pull 操 作 (不 带 参 数 ) 将 远程 版 本 库 中 其 他 
人 推送 的 提交 获取 到 本 地 。 这 是 因为 没有 建立 本 地 分 支 和 远程 分 支 的 追 


踪 ， 即 没有 设置 branch.<branchname>.remote 的 值 和 branch. 





<branchname>.merge 的 值 。 
关于 不 带 参数 执行 git pull 命 令 的 解释 如 下 : 


. 如 果 为 当前 分 支 设置 了 ， 即 由 配置 branch..remote 出 了 远程 版 本 详 
代号 ， 则 不 带 参数 执行 git pull 相 当 于 执行 了 git pull。 


` 如 果 没 有 为 当前 分 支 设 置 ， 则 不 带 参 数 执行 git pull 相 当 于 执行 了 
git pull otipgin 。 


' 要 获取 的 远程 版 本 库 的 URL 地 址 由 remote..utl 给 出 。 


. 如 果 为 注册 的 远程 版 本 库 设置 了 fetch 参 数 ， 即 通过 remote..fetch 配 
置 了 一 个 引用 表达 式 ， 则 使 用 该 引用 表达 式 执 行 获取 操作 。 


. 接 下 来 要 确定 合并 的 分 支 。 如 果 设 定 了 branch..metge， 则 对 其 设 
定 的 分 支 执行 合并 ， 否 则 报错 退出 。 


在 执行 git pull 操 作 的 时 候 可 以 通过 参数 --rebase 设 置 使 用 变 基 而 非 合 
并 操作 ， 将 本 地 分 文 的 改动 变 基 到 跟踪 分 文 上 。 为 了 避免 因为 筷 记 使 
用 --rebase 参 数 导 致 分 文 的 合并 ， 可 以 执行 如 下 命令 进行 设置 。 注 意 将 
<branchname> 答 换 为 对 应 的 分 文 名 称 。 








$ git config branch.<branchname>.rebase true 





有 了 这 个 设置 之 后 ， 如 果 是 在 <branchname> 工 作 分 文中 执行 git pull 
命令 ， 在 遇 到 本 地 分 文 和 远程 分 文 出 现 侦 离 的 情况 时 ， 会 采用 变 基 操 
作 ， 而 不 是 默认 的 合并 操作 。 





如 果 为 本 地 版 本 库 设 置 参数 branch.autosetuprebase， 值 为 tue， 则 在 
基于 远程 分 支 建 立 本 地 追踪 分 文 时 ， 会 自动 配置 branch. 
<branchname>.rebase 参 数 ， 在 执行 git pull 命 令 时 使 用 变 基 操 作 取 代 默 认 
的 合并 操作 。 


19.5 ”里程碑 和 远程 版 本 库 


远程 版 本 库 中 的 里 程 碑 同步 到 本 地 版 本 库 ， 会 使 用 同样 的 名 称 ， 而 
不 会 像 分 支那 样 移动 到 男 外 的 命名 空间 (远程 分 支 ) 中 ， 会 给 本 
地 版 本 库 中 的 里 程 碑 带 来 混乱 。 当 和 多 个 远程 版 本 库 交 互 时 ， 这 个 问题 


前 面 的 Git 里 程 碑 一 章 已 经 介绍 了 当 执 行 git push 命 令 推送 时 ， 默 认 
不 会 将 本 地 创建 的 里 程 碑 带 入 远程 版 本 库 ， 这 样 可 以 避免 远程 版 本 库 上 
里 程 碑 的 泛滥 。 但 是 执行 git fetch 命 令 从 远程 版 本 库 获 取 分 支 的 最 新 提 
交 时 ， 如 果 获 取 的 提交 上 建 有 里 程 碑 ， 这 些 里 程 碑 会 被 获取 到 本 地 版 本 
库 。 当 删除 注册 的 远程 版 本 库 时 ， 远 程 分 支 会 被 删除 ， 但 是 该 远程 版 本 
库 引 入 的 里 程 碑 不 会 被 删除 ， 日 积 月 累 本 地 版 本 库 中 的 里 程 碑 可 能 会 变 

得 愈加 混乱 。 





可 以 在 执行 git fetch 命 令 的 时 候 ， 设 置 不 获取 里 程 碑 只 获取 分 文 及 
提交 。 通 过 提供 -n 或 --no-tags 参 数 可 以 实现 。 示 例如 下 : 


$ git fetch --no-tags file:///path/to/repos/hello-world.git \ 
refs/heads/*:refs/remotes/hello-world/* 


在 注册 远程 版 本 库 的 时 候 ， 也 可 以 使 用 --no-tags 参 数 ， 避 免 将 远程 
版 本 库 的 里 程 碑 引入 本 地 版 本 库 。 例 如 : 


一 


$ git remote add --no-tags hell-world \ 
file:///path/to/repos/hello-world.git 


mn | 


19.6 分 支 和 里 程 碑 的 安全 性 


通过 前 面 章节 的 探讨 ， 会 感觉 到 Git 的 使 用 真 的 是 太 方便 、 太 有 灵活 
了 ， 但 是 需要 掌握 的 知识 点 和 守门 也 太 多 了 。 为 了 避免 没有 经 验 的 用 户 
在 团队 共享 的 Git 版 本 库 中 误 操 作 ， 就 需要 对 版 本 库 进 行 一 些 安 全 上 的 
设置 。 本 书 第 5 篇 Git 服 务 器 搭建 的 相关 章 市 会 具体 介绍 如 何 配 置 用 户 授 
权 等 版 本 库 安 全 性 设置 。 





实际 上 Git 版 本 库 本 身 也 提供 了 一 些 安 全 机 制 避免 对 版 本 库 的 破 
坏 。 


* 用 reflog 记 录 对 分 支 的 操作 历史 


默认 创建 的 带 工作 区 的 版 本 库 都 会 包含 core.logallrefupdates 为 true 的 
配置 ， 这 样 在 版 本 库 中 建立 的 每 个 分 支 都 会 创建 对 应 的 reflog。 但 是 创 
建 的 裸 版 本 库 默 认 不 包含 这 个 设置 ， 也 就 不 会 为 每 个 分 支 设 置 reflog。 
如 果 团 队 的 规模 较 小 ， 可 能 因为 分 支 误 操作 导致 数 据 丢 失 ， 可 以 考虑 为 
裸 版 本 库 添 加 core.logallrefupdates 的 相关 配置 。 





. 关闭 非 快 进 式 推送 。 


如 果 将 配置 receive.denyNonFastForwards 设 置 为 tue， 则 禁止 一 切 非 
快 进 式 推送 。 但 这 个 配置 有 些 矫 枉 过 正 ， 更 好 的 方法 是 搭建 基于 SSH 协 





议 的 Git 服 务 器 ， 通 过 钩子 脚本 更 灵活 地 进行 配置 。 例 如 : 允许 来 自 茶 
些 用 户 的 强制 提交 ， 而 其 他 用 户 不 能 执行 非 快 进 式 推送 。 


关闭 分 支 删除 功能 。 


如 有 果 将 配置 receive.denyDeletes 设 置 为 tue， 则 禁止 删除 分 支 。 同 样 
更 好 的 方法 是 通过 架设 基于 SSH 协 议 的 Git 服 务 妖 ， 配 置 分 文 删 除 的 用 户 
权限 。 


第 20 章 ”补丁 文件 交互 


之 前 各 个 





节 的 版 本 库 间 的 交互 都 是 通过 git push 和 /或 git pull 命 令 
来 实现 的 ， 这 是 Git 最 主要 的 交互 模式 ， 但 并 不 是 全 部 。 使 用 补丁 文件 
是 另外 一 种 交互 方式 ， 适 用 于 参与 者 众多 的 大 型 项 目 进行 的 分 布 式 开 
发 。 例 如 Git 项 目 本 号 的 代码 提交 就 主要 由 贡献 者 通过 邮件 传递 补丁 文 
件 来 实现 的 。 作 者 在 写 书 过 程 中 发 现 了 Git 的 两 个 Bug， 就 是 以 补丁 形式 
通过 邮件 贡献 给 Git 项 目的 ， 下 面 两 个 链接 就 是 相关 邮件 的 存档 。 





关于 Git 文 档 错 误 的 Bugfix: 
http://marc.info/?l=git&m=129248415230151 

关于 git-apply 的 一 个 Bugfix: 
http://article.gmane.org/gmane.comp.version-control.git/162100 


这 种 使 用 补丁 文件 进行 提 区 的 方式 可 以 提高 项 目的 参与 度 。 因 为 任 


何人 都 可 以 参与 项 目的 开发 ， 只 要 会 将 提交 转化 为 补丁 ， 会 发 邮件 即 
可 。 


20.1 创建 补丁 


Git 提 供 了 将 提交 批量 转换 为 补丁 文件 的 命令 : git format-patch。 该 
命令 后 面 的 参数 是 一 个 版 本 范围 列表 ， 会 将 包含 在 此 列表 中 的 提交 一 一 
转换 为 补丁 文件 ， 每 个 补丁 文件 包含 一 个 序号 并 从 提交 说 明 中 提取 字符 
串 作 为 文件 名 。 








下 面 演 示 一 下 在 user1 工 作 区 中 ， 如 何 将 master 分 支 的 最 近 3 个 提交 
转换 为 补丁 文件 。 


(1) 进入 user1 工 作 区 ， 切 换 到 master 分 文 。 





$ cd /path/to/user1i/workspace/hello-world/ 
$ git checkout master 
$ git pull 





(2) 执行 下 面 的 命令 将 最 近 3 个 提交 转换 为 补丁 文件 。 





$ git format-patch -s HEAD~3. .HEAD 
©0001-Fix-typo-help-to-help.patch 
©0002-Add-I1l8N-support.patch 
0003-Translate-for-Chinese.patch 





在 上 面 的 git format-patch 命 令 中 使 用 了 -s 参 数 ， 会 在 导出 的 补丁 文件 
中 添加 当前 用 户 的 签名 。 这 个 签名 并 非 GnuPG 式 的 数字 签名 ， 不 过 是 将 
作者 姓名 添加 到 提交 说 明 中 而 已 ， 和 在 本 书 第 2 篇 开头 介绍 的 git commit- 





s 命 令 的 效果 相同 。 虽 然 签名 很 不 起 眼 ， 但 是 对 于 以 补丁 的 方式 提交 数 
据 却 非常 重要 ， 因 为 以 补丁 方式 的 所 交 可 能 因为 合并 冲突 或 其 他 原因 使 
得 最 终 提 交 的 作者 ID 显示 为 代为 提 区 的 项 目 管理 员 的 ID， 在 提交 说 明 中 
加 入 原始 作者 的 普 名 信息 大 概 是 作者 唯一 露脸 的 机 会 。 如 果 在 提交 时 到 
了 使 用 -s 参 数 添 加 签名 ， 可 以 在 用 git format-path 命 令 创 建 补丁 文件 的 时 
候补 救 。 








看 一 下 补丁 文件 的 文件 头 ， 在 下 面 代码 中 的 第 7 行 可 以 看 到 新 增 的 
签名 。 


MW 





1 From d81896e60673771ef1873b27a33f52df75f70515 Mon Sep 17 00:00:00 2001 
2 From: user1 <user1i@sun.ossxp.com> 

3 Date: Mon, 3 Jan 2011 23:48:56 +0800 

4 Subject: [PATCH 1/3] Fix typo: -help to --help. 


5 

6 

7 Signed-off-by: user1 <user1@sun.ossxp.com> 
8 --- 

9 src/main.c | 2 +- 


10 1 files changed, 1 insertions(+), 1 deletions(-) 





补丁 文件 有 一 个 类 似 邮 件 一 样 的 文件 头 《〈 第 1~4 行 ) ， 提 区 日 志 的 
第 一 行 作为 邮件 标题 (Subject〉， 其 余 的 提交 说 明 作 为 邮件 内 容 (如果 
有 的 话 ) ， 文 件 补丁 用 三 个 横 线 和 提交 说 明 分 开 。 





实际 上 这 些 补丁 文件 可 以 直接 拿 来 作为 邮件 发 送 给 项 目的 负责 人 。 
Git 提 供 了 一 个 辅助 邮件 发 送 的 命令 git send-email。 下 面 用 该 命令 将 这 三 
个 补丁 文件 以 邮件 的 形式 发 送出 去 。 





$ git send-email *.patch 


©0001-Fix-typo-help-to-help.patch 

©0002-Add-I18N-support.patch 

0003-Translate-for-Chinese.patch 

The following files are 8bit, but do not declare a Content-Transfer-Encoding. 
0002-Add-I18N-support.patch 
0003-Translate-for-Chinese.patch 

Which 8bit encoding should I declare [UTF-8]? 

Who should the emails appear to be from? [user1 <user1i@sun.ossxp.com>] 

Emails will be sent from: user1 <useri@sun.ossxp.com> 

Who should the emails be sent to? jiangxin 

Message-ID to be used as In-Reply-To for the first email? 


send this email? ([yjes|[njol[9q]juit|[a]ll): a 





命令 git send-email 提 供 交 互 式 字符 界面 ， 输 入 正确 的 收 件 人 地 址 ， 
邮件 就 批量 地 发 送出 去 了 。 


20.2 ”应 用 补丁 


在 前 面 通过 git send-email 命 令 发 送 邮 件 给 jiangxin 用 户 。 现 在 使 用 
Linux 上 的 mail 命 令 检查 一 下 邮件 。 





$ mail 
Mail version 8.1.2 01/15/2001. Type ? for help. 
"/var/mail/jiangxin": 3 messages 3 unread 
>N 1 useri@sun.ossxp.c Thu Jan 13 18:02 38/1120 [PATCH 1/3] Fix typo: -help to 
N 2 useri@sun.ossxp.c Thu Jan 13 18:02 227/6207 
=?UTF-8?q?=5BPATCH=202/3=5D=20Add=20I18N=20support=2E?= 
N 3 useri@sun.ossxp.c Thu Jan 13 18:02 95/2893 
=?UTF-8?q?=5BPATCH=203/3=5D=20Translate=20for=20Chinese=2E?= 








如 末 邮 件 不 止 这 三 封 ， 需 要 将 三 个 包含 补丁 的 邮件 挑选 出 来 保存 到 
另外 的 文件 中 。 例 如 在 mail 命 令 的 提示 符 《〈&) 下 输入 命令 将 选 定 的 邮 
件 保 存 为 单独 的 文件 。 





& S 1-3 useri-mail-archive 
"User1-mail-archive” [New file] 
& 9 





上 面 的 操作 在 本 地 创建 了 一 个 由 开发 者 userl 的 补丁 邮件 组 成 的 归档 
文件 userl1-mail-archive， 这 个 文件 是 mbox 格 式 的 ， 可 以 用 mail 命 令 打 
Ts 





$ mail -f useri-mail-archive 

Mail version 8.1.2 01/15/2001. Type ? for help. 

"useri-mail-archive": 3 messages 

> 1 useri@sun.ossxp.c Thu Jan 13 18:02 38/1121 [PATCH 1/3] Fix typo: -help to 
2 useri@sun.ossxp.c Thu Jan 13 18:02 227/6208 =?UTF-8?q?=5BPATCH=202/3=5D=20/ 


3 useri@sun.ossxp.c Thu Jan 13 18:02 95/2894 =?UTF-8?q?=5BPATCH=203/3=5D=201 
& 9 





使 用 git am 命令 可 以 使 得 保存 在 mbox 中 的 邮件 批量 地 应 用 在 版 本 库 
中 。am 是 apply email 的 缩写 。 下 面 就 演示 一 下 如 何 使 用 git am 命令 应 用 
补丁 ， 具 体操 作 过 程 如 下 。 


(1) 基于 HEAD~3 版 本 创建 一 个 本 地 分 文 ， 以 便 在 该 分 文 下 应 用 
补丁 。 





$ git checkout -b user1 HEAD~3 
Switched to a new branch "User1' 








(2) 将 mbox 文 件 user1-mail-archive 中 的 补丁 全 部 应 用 在 当前 分 支 
-i 





$ git am useri-mail-archive 
Applying: Fix typo: -help to --help. 
Applying: Add I18N support. 
Applying: Translate for Chinese. 





(3) 补丁 成 功 应 用 上 了 ， 看 看 提交 日 志 。 





$ git 1og -3 --pretty=fuller 
commit 2d9276af9df1a2fdb71d1e7c9ac6dff88b2920al1 


Author: Jiang Xin <jiangxin@ossxp.com> 
AuthorDate: Thu Jan 13 18:02:03 2011 +0800 
Commit: USer1 <user1@sun.ossxp.com> 


CommitDate: Thu Jan 13 18:21:16 2011 +0800 
Translate for Chinese. 
Signed-off-by: Jiang Xin <jiangxin@ossxp.com> 
Signed-off-by: user1 <user1iQ@sun.ossxp.com> 
commit 41227f492ad37cdd99444a5f5cc0c27288f2bca4 


Author: Jiang Xin <jiangxin@ossxp.com> 
AuthorDate: Thu Jan 13 18:02:02 2011 +0800 
Commit: USer1 <user1@sun.ossxp.com> 


CommitDate: Thu Jan 13 18:21:15 2011 +0800 


Add I18N support. 

Signed-off-by: Jiang Xin <jiangxin@ossxp.com> 

Signed-off-by: user1 <user1iQ@sun.ossxp.com> 
commit 4a3380fb7ae90039633dec84acc2aab85398efad 


Author: USer1 <user1@sun.ossxp.com> 
AuthorDate: Thu Jan 13 18:02:01 2011 +0800 
Commit: USer1 <user1i@sun.ossxp.com> 


CommitDate: Thu Jan 13 18:21:15 2011 +0800 
Fix typo: -help to --help. 
Signed-off-by: user1 <user1i@sun.ossxp.com> 





从 提交 信息 中 可 以 看 出 : 
: 提交 的 时 间 信 息 使 用 了 邮件 发 送 的 时 间 。 
- 作者 (Author) 的 信息 被 保留 ， 和 补丁 文件 中 的 一 致 。 
. 提交 者 (Commit) 全 都 设置 为 user1， 因 为 提交 是 在 user1 的 工作 
区 完成 的 。 


` 提交 说 明 中 的 签名 信息 被 保留 。 实 际 上 git am 命 令 也 可 以 提供 -s 参 


信 人 > 


数 ， 在 提交 说 明 中 附加 执行 命令 用 户 的 签名 。 


对 于 不 习惯 在 控制 台 用 mail 命 令 接 收 邮件 的 用 户 ， 可 以 通过 邮件 附 
件 、U 盘 或 其 他 方式 获取 git format-patch 生 成 的 补丁 文件 ， 将 补丁 文件 保 
存在 本 地 ， 通 过 管道 符 调用 git am 命令 应 用 补丁 。 





$ ls *,patch 
©0001-Fix-typo-help-to-help.patch 0002-Add-I18N-support.patch 
0003-Translate-for-Chinese.patch 

$ cat *.patch | git am 

Applying: Fix typo: -help to --help. 

Applying: Add I18N support. 

Applying: Translate for Chinese. 


ee | 


Git 还 提供 一 个 命令 git apply， 可 以 应 用 一 般 格 式 的 补丁 文件 ， 但 是 
不 能 执行 提交 ， 也 不 能 保持 补丁 中 的 作者 信息 。 实 际 上 git apply 命 令 和 
GNU patch 命 令 类 似 ， 细 微 差 别 将 在 本 书 第 7 篇 的 “第 38 章 ”补丁 中 的 二 
进 制 文件 ”中 予以 介绍 。 


20.3 StGit 和 Quilt 





一 个 复杂 功能 的 开发 一 定 是 由 多 个 提交 来 完成 的 ， 对 于 在 以 接收 和 
应 用 补丁 文件 为 开发 模式 的 项 目 中 ， 复 杂 的 功能 需要 通过 多 个 补丁 文件 
来 完成 。 补 丁 文件 因为 要 经 过 审核 才能 被 接受 ， 因 此 针对 一 个 功能 的 多 
个 补丁 文件 一 定 要 保证 各 个 都 是 精品 : 补丁 1 用 来 完成 一 个 功能 点 ， 补 
丁 2 用 来 完成 第 二 个 功能 点 ， 等 等 。 一 定 不 能 出 现 这 样 的 情况 ， 补丁 3 用 
于 修正 补丁 1 的 错误 ,补丁 10 改 正 了 补丁 7 中 的 文字 错误 ， 等 等 。 这 样 就 
带 来 补丁 管理 的 难题 。 








实际 上 基于 特性 分 文 的 开发 又 何尝 不 是 如 此 ? 在 将 特性 分 文 归 并 到 
开发 主线 前 ， 要 接受 团队 的 评审 ， 特 性 分 文 的 开发 者 一 定 想 将 特性 分 文 
上 的 提交 进行 重 整 ， 把 一 些 提交 合并 或 拆 分 。 使 用 变 基 命令 可 以 实现 提 
区 的 重 整 ， 但 是 操作 起 来 会 比较 困难 ， 有 什么 好 办 法 呢 ? 


20.3.1 StGit 


StGit 1 是 Stacked Git 的 简称 。StGit 就 是 解决 上 面 提 到 的 两 个 难题 的 


答案 。 实 际 上 StGit 在 设计 上 参考 了 一 个 着 名 的 补丁 管理 工具 Quilt， 并 且 
可 以 输出 Quilt 兼 容 的 补丁 列表 。 在 本 节 的 后 半 部 分 会 介绍 Quilt。 











StGit 是 一 个 Python 项 目 ， 安 装 起 来 还 是 很 方便 的 。 在 Debian/Ubuntu 





下 ， 可 以 直接 通过 包 管 理 器 安装 : 





$ sudo aptitude install stgit stgit-contrib 





下 面 还 是 用 hello-world 版 本 库 ， 进 行 StGit 的 实践 。 


(1) 首先 检 出 hello-world 版 本 库 。 





$ cd /path/to/my/workspace/ 
$ git clone file:///path/to/repos/hello-world.git stgit-demo 
$ cd stgit-demo 





(2) 在 当前 工作 区 初始 化 StGit。 





$ stg init 





(3) 现在 补丁 列表 为 空 。 





$ stg series 





(4) 将 最 新 的 三 个 提交 转换 为 StGit 补 丁 。 





$ stg uncommit -n 3 
Uncommitting 3 patches ... 

Now at patch "translate-for-chinese" 
done 








(5) 现在 补丁 列表 中 有 三 个 文件 了 。 


第 一 列 是 补丁 的 状态 符号 。 加 号 〈+) 代表 该 补丁 已 经 应 用 在 版 本 





库 中 ， 大 于 号 《>) 用 于 标识 当前 的 补丁 。 





$ stg ser 

+ fix-typo-help-to-help 
+ add-i1i8n-support 

> translate-for-chinese 





(6) 现在 碍 看 master 分 文 的 日 志 ， 发 现 和 之 前 没有 两 样 。 





$ git 1og -3 --oneline 

c4acab2 Translate for Chinese. 
683448a Add I18N support. 

d81896e Fix typo: -help to --help. 





(7) 执行 StGit 补 本 出 栈 的 命令 ， 会 将 补丁 撤 出 应 用 。 使 用 -a 参 数 
会 将 所 有 补丁 撤 出 应 用 。 





$ stg pop 

Popped translate-for-chinese 

Now at patch "add-ii8n-support" 

$ stg pop -a 

Popped add-ii8n-support -- fix-typo-help-to-help 
No patch applied 








(8) 再 来 看 看 版 本 库 的 日 志 ， 会 发 现 最 新 的 三 个 提交 都 不 见 了 。 





$ git 1og -3 --oneline 

10765a7 Bugfix: allow spaces in username. 

©0881ca3 Refactor: use getopt_long for arguments parsing. 
ebcf6d6 blank commit for GnuPG-signed tag test. 





(9) 得 看 补丁 列表 的 状态 ， 会 看 到 每 个 补丁 前 都 用 减 号 《〈-) 标 





stg ser 
fix-typo-help-to-help 

- add-i1i8n-support 

- translate-for-chinese 





(10) 执行 补丁 入 栈 ， 即 应 用 补丁 ， 使 用 命令 stg push 或 stg goto， 
注意 stg push 命 令 和 git push 命 令 风 马 牛 不 相 及 。 





$ stg push 

Pushing patch "fix-typo-help-to-help" ... done (unmodified ) 
Now at patch "fix-typo-help-to-help" 

$ stg goto add-i1i8n-support 

Pushing patch "add-ii8n-support" ... done (unmodified) 

Now at patch "add-i1i8n-support" 








(11) 现在 处 于 应 用 add-il8n-support 补 本 的 状态 。 这 个 补丁 有 些 问 
题 ， 本 地 化 语言 模板 有 错误 ， 我 们 来 修改 一 下 。 








$ cd src/ 

$ rm locale/helloworld.pot 

$ make po 

xgettext -s -k_ -0o locale/helloworld.pot main.c 

msgmerge locale/zh_ CN/LC MESSAGES/helloworld.po locale/helloworld.pot -0 locale/temr 
mv locale/temp.po locale/zh_CN/LC_ MESSAGES/helloworld.po 








(12) 现在 查看 工作 区 ， 发 现 工作 区 有 改动 。 





$ git status -s 
M locale/helloworld.pot 
M locale/zh_CN/LC_ MESSAGES/helloworld.po 





(13) 不 要 提交 ， 而 是 执行 stg refresh 命 令 更 新 补丁 。 





$ stg refresh 
Now at patch "add-i1i8n-support" 





(14) 这 时 再 查看 工作 区 ， 发 现 本 地 修改 不 见 了 。 





$ git status -s 





(15) 执行 stg show 会 看 到 当前 的 补丁 add-i18n-support 已 经 更 新 。 





$ stg show 





(16) 将 最 后 一 个 补丁 应 用 到 版 本 库 ， 过 到 冲突 。 这 是 因为 最 后 一 
个 补丁 是 对 中 文本 地 化 文件 的 翻译 ， 因 为 翻译 前 的 模板 文件 被 更 改 了 所 
以 造成 了 冲突 。 





$ stg push 
Pushing patch "translate-for-chinese" ... done (conflict) 
Error: 1 merge conflict(s) 
CONFLICT (content): Merge conflict in 
src/locale/zh_CN/LC_ MESSAGES/helloworld.po 
Now at patch "translate-for-chinese" 





(17) 这 个 冲突 文件 很 好 和 解雇， 直接 编辑 冲突 文件 helloworld.po 即 
可 。 编 辑 好 之 后 ， 注 意 一 下 第 50 行 和 第 62 行 是 否 像 下 面 写 的 一 样 。 








50 " hello -h, --help\n" 

51 " 显示 本 帮助 页 。\n" 
61 msgid "Hi, " 

62 msgstr "您 好 ，" 





(18) 执行 git add 命 令 完 成 冲突 解决 。 





$ git add locale/zh_CN/LC_MESSAGES/helloworld.po 





(19) 不 要 提交 ， 而 是 使 用 stg refresh 命 令 更 新 补丁 ， 同 时 更 新 提 


MN| 
J 





$ stg refresh 
Now at patch "translate-for-chinese" 
$ git status -s 





(20) 看 看 修改 后 的 程序 ， 是 不 是 都 能 显示 中 文 了 。 





$ ./hello 

世界 你 好 。 

(version: v1.0-5-g733c6ea) 
$ ./hello Jiang Xin 

您 好 ， Jiang Xin. 

(version: v1.0-5-g733c6ea) 
$ ./hello -h 








(21) 导出 补丁 ， 使 用 命令 stg export。 导 出 的 是 Quilt 格 式 的 补丁 
集 。 





$ cd /path/to/my/workspace/stgit-demo/ 
$ stg export -d patches 
Checking for changes in the working directory ... done 








(22) 看 看 导出 补丁 的 目标 目录 。 





$ ls patches/ 
add-ii8n-support fix-typo-help-to-help series translate-for-chinese 





(23) 其 中 文件 series 是 补丁 文件 的 列表 ， 列 在 前 面 的 补丁 先 家 应 
用 。 


$ cat patches/series 

# This series applies on GIT commit d81896e60673771ef1873b27a33f52df75f70515 
fix-typo-help-to-help 

add-i18n-Support 

translate-for-chinese 








通过 上 面 的 演示 可 以 看 出 StGit 可 以 非常 方便 地 对 提交 进行 整理 ， 整 
理 提交 时 无 须 使 用 复杂 的 变 基 命令 ， 而 是 采用 提交 StGit 化 、 修 改 文件 、 
执行 stg refresh 的 工作 流程 即 可 更 新 补丁 和 提交 。StGit 还 可 以 将 补丁 导 
出 为 补丁 文件 ， 虽 然 导 出 的 补丁 文件 没有 像 git format-patch 那 样 加 上 代 
表 顺 序 的 数字 前 级 ， 但 是 用 文件 series 标 注 了 补丁 文件 的 先后 顺序 。 实 
际 上 可 以 在 执行 stg export 时 添加 -n 参 数 为 补丁 文件 添加 数字 前 级 。 


StGit 还 有 一 些 功 能 ， 如 合并 补丁 /提交 ， 插 入 新 补丁 /提交 等 ， 请 参 
照 StGit 帮 助 ， 恕 不 一 一 举例 。 


20.3.2 Quilt 


Quilt 后 是 一 款 补丁 列表 管理 软件 ， 用 Shell 语 言 开发 ， 安 装 也 很 简 
单 ， 在 Debian/Ubuntu 上 直接 用 下 面 的 命令 即 可 安装 : 





$ sudo aptitude install quilt 








Quilt 约 定 俗 成 将 补丁 集 放 在 项 目 根 目 录 下 的 子 目 录 patches 中 ， 人 否则 
需要 通过 环境 变量 QUILT_ PATCHES 对 路 径 进行 设置 。 为 了 减少 麻烦 ， 
在 上 面 用 stg export 导 出 补丁 的 时 候 就 导出 到 了 patches 目 录 下 。 


简单 说 一 下 Quilt 的 使 用 ， 会 发 现 真 的 和 StGit 很 像 ， 实 际 上 是 先 有 的 
Quilt， 后 有 的 StGit。Quilt 使 用 过 程 如 下 。 


(1) 重 置 到 三 个 提交 前 的 版 本 ， 人 否则 应 用 补丁 的 时 候 会 失败 。 不 
要 忘 了 删除 srclocale 目 录 。 





$ git reset --hard HEAD~3 
$ rm -rf src/locale/ 








(2) 显示 补丁 列表 。 





$ quilt series 
01-fix-typo-help-to-help 
02-add-i1i8n-support 
03-translate-for-chinese 





(3) 应 用 一 个 补丁 。 





$ quilt push 

Applying patch 01-fix-typo-help-to-help 
patching file src/main.c 

Now at patch 01-fix-typo-help-to-help 





(4) 下 一 个 补丁 是 什么 ? 





$ quilt next 
02-add-i1i8n-support 





(5) 应 用 全 部 补丁 。 





$ quilt push -a 
Applying patch 02-add-i1i8n-support 


patching file src/Makefile 

patching file src/locale/helloworld.pot 

patching file src/locale/zh_CN/LC_ MESSAGES/helloworld.po 
patching file src/main.c 

Applying patch 03-translate-for-chinese 

patching file src/locale/zh_CN/LC_ MESSAGES/helloworld.po 
Now at patch 03-translate-for-chinese 





Quilt 的 功能 还 有 很 多 ， 请 参照 Quilt 的 在 线 帮助 ， 息 不 一 一 举例 。 


Git 提 供 了 一 个 名 为 git quiltimport 的 命令 ， 可 以 非常 方便 地 将 Quilt 格 
式 的 补丁 集 转化 为 一 个 一 个 的 Git 提 交 ， 是 前 面 介绍 的 git am 命令 的 一 个 
补充 。 例 如 要 将 位 于 patches 目 录 下 的 Quilt 补 丁 集 应 用 到 版 本 库 中 ， 可 以 
执行 下 面 的 命令 : 





$ git quiltimport 





[1] http:/ /www.procode.org/stgit/ 


[2] http:/ /savannah.nongnu.org/projects/ quilt 


第 4 篇 ”Git 协 同 模型 


分 布 式 的 版 本 控制 会 不 会 造成 开发 中 的 无 序 ， 导 致 版 本 管理 的 崩 
沉 ? 习惯 了 如 Subversion 这 类 集中 式 版 本 控制 系统 的 用 户 一 定 会 有 这 个 


疑问 。 





作为 分 布 式 版 本 控制 系统 ， 每 一 个 克隆 都 是 一 个 完整 的 版 本 库 ， 可 
以 提供 一 个 版 本 控制 服务 器 所 能 提供 的 一 切 服务 ， 即 每 个 人 的 电脑 都 是 
一 台 服 务 器 。 与 之 相反 ， 像 Subversion 那 样 的 集中 式 版 本 控制 系统 ， 只 
拥有 唯一 的 版 本 控制 服务 器 ， 所 有 团队 成 员 都 使 用 客户 端 与 之 交互 ， 大 
部 分 操作 要 通过 网 络 传输 来 实现 。 对 于 习惯 了 和 唯一 服务 器 交互 的 团 
队 ， 转 换 到 Git 后 ， 该 如 何 协同 团队 的 工作 呢 ?“ 第 21 章 ”经 典 Git 协 同 模 
型 ”会 介绍 集中 式 和 社交 网 络 式 两 种 主要 的 协同 工作 模型 。 








基于 东 个 项 目 进行 二 次 开发 ， 需 要 使 用 不 同 的 工作 模型 。 原 始 的 项 
目 称 为 上 游 项 目 ， 不 能 直接 在 上 游 项 目 中 提交 ， 可 能 是 因为 授权 的 原 
因 ， 或 者 是 因为 目标 用 户 的 需求 不 同 。 这 种 基于 上 游 项 目 进行 二 次 开 
发 ， 实 际 上 是 对 各 个 独特 的 功能 分 文 进行 管理 ， 同 时 又 能 对 上 游 项 目的 
开发 进度 进行 兼 收 并 蓄 式 的 合并 。“ 第 22 音 ”Topgit 协 同 模型 ”会 重点 介 
绍 这 一 方面 的 内 容 。 





多 个 版 本 库 组 成 一 个 项 目 ， 在 实际 应 用 中 并 不 罕见 。 一 部 分 原因 可 








能 是 版 本 库 需 要 依赖 第 三 方 的 版 本 库 ， 这 时 第 23 章 介绍 的 “ 子 模 组 协同 
模型 * 就 可 以 派 上 用 场 了 。 有 的 时 候 还 要 对 第 三 方 的 版 本 库 进 行 定 

制 ，“ 第 24 章 ” 子 树 合并 ”提供 了 一 个 解决 方案 。 有 的 时 候 ， 为 了 管理 方 
便 《 授 权 或 项 目 确实 太 庞 杂 ) ， 多 个 版 本 库 共同 组 成 一 个 大 的 项 目 ， 例 
如 Google Android 项 目 就 是 由 近 200 个 版 本 库 组 成 的 。“ 第 25 章 ”Android 
式 多 版 本 库 协同 ”提供 了 一 个 非常 有 趣 的 解决 方案 ， 解决 了 “ 子 模 组 协同 
模型 ”管理 上 的 难题 。 




















在 本 篇 的 最 后 《第 26 章 ) ， 会 介绍 gitrsvn 这 一 工具 。 可 能 因为 公司 
对 代码 严格 的 授权 要 求 ， 而 不 能 将 公司 的 版 本 控制 服务 器 从 Subversion 
迁移 到 Git (实际 可 以 通过 对 Git 版 本 库 细 粒度 拆 分 实现 授权 管理 ) ， 可 
是 这 并 不 能 阻止 个 人 使 用 gitrsvn 作 为 前 端 工具 操作 Subversion 版 本 库 。 
git-svn 可 以 让 Git 和 Subversion 完 美 地 协同 工作 。 








第 21 章 ”经典 Git 协 同 模型 


21.1 集中 式 协同 模型 


可 以 像 集中 式 版 本 控制 系统 那样 使 用 Git， 在 一 个 大 家 都 可 以 访问 
到 的 服务 器 上 架设 Git 服 务 器 ， 所 有 人 都 可 以 从 该 服务 器 克隆 代码 ， 将 
本 地 提交 推送 到 服务 器 上 ， 如 图 21-1 所 示 。 


共享 的 版 本 库 






图 21-1 集中 式 协 同 模 型 


回忆 一 下 在 使 用 Subversion 等 集中 式 版 本 控制 系统 时 ， 对 服务 器 管 
理 上 的 要 求 : 


" 只 允许 拥有 账号 的 用 户 访问 版 本 库 。 


" 甚至 只 允许 用 户 访问 版 本 库 中 的 某 些 路 径 ， 其 他 路 径 则 不 能 访 


问 。 

* 特定 目录 只 允许 特定 用 户 执 行 写 操作 。 

` 服务 器 可 以 通过 钩子 实现 特殊 功能 ， 如 对 commit log 的 检查 、 数 
据 镜 像 等 。 


对 于 这 些 再 求 ，Git 大 部 分 都 能 文 持 ， 甚 至 能 够 做 到 更 多 : 


` 可 以 设置 谁 能 访问 版 本 库 ， 谁 不 能 访问 版 本 库 。 


. 具有 更 丰富 的 写 操作 授权 。 可 以 限制 哪些 分 支 不 允许 写 ， 哪 些 路 
径 不 允许 写 。 


` 可 以 设置 谁 能 够 创建 新 的 分 


可 以 设置 谁 能 够 创建 新 的 版 本 库 。 


` 可 以 设置 谁 能 够 强制 更 新 。 


` 服务 器 端 同 样 支持 钩子 脚本 。 


当然 想 要 完整 地 实现 上 述 的 功能 需求 ， 需 要 使 用 特殊 的 服务 器 软件 
(如 Gitolite) 来 架设 Git 服 务 器 ， 这 也 是 通过 Git 实 现 传统 集中 式 工 作 模 
型 的 核心 。 在 本 书 第 5 篇 介绍 服务 器 部 署 的 时 候 ， 会 介绍 如 何 用 Gitolite 














架设 Git 服 务 器 ， 以 实现 集中 式 协同 模型 对 版 本 库 授 权 和 管理 上 的 要 
求 。 





但 是 也 要 承认 ， 在 * 读 授权 ”上 Git 做 不 到 很 精细 ， 这 是 分 布 式 版 本 控 
制 系统 的 机 制 使 然 。 按 模块 分 解 Git 版 本 库 ， 并 结合 后 面 介绍 的 多 版 本 
库 协同 解决 方案 可 以 克服 Git 读 授权 的 局 限 。 


* Git 不 支持 对 版 本 库 读 取 的 精确 授权 ， 只 能 是 非 0 即 1 的 授权 。 即 
或 者 能 够 读 取 一 个 版 本 库 的 全 部 ， 或 者 什么 也 读 不 到 。 


因为 Git 的 提交 是 一 个 整体 ， 提 交 中 包含 了 完整 目录 树 (tree) 的 


哈 希 值 ， 因 此 完整 性 不 容 破 坏 。 


" Git 是 分 布 式 版 本 控制 系统 ， 如 果 允 许 不 完整 的 克隆 ， 那 么 本 地 
就 是 截然 不 同 的 版 本 库 ， 在 向 服务 器 推送 的 时 候 ， 会 被 拒绝 ， 或 者 产生 
新 的 分 支 。 





21.1.1 传统 集中 式 协 同 模型 


对 于 简单 的 代码 修改 ， 可 以 像 传统 集中 式 版 本 控制 系统 
(Subversion〉 那样 工作 ， 参 照 图 21-2 所 示 的 工作 流程 图 。 





和 rebase 






git pull 





git 





图 21-2 集中 式 协 同 模 型 工作 流 1 


但 是 对 于 复杂 的 修改 (代码 重 构 / 增 加 复杂 功能 ) ， 这 个 工作 模式 
就 有 些 不 合适 了 。 





第 一 个 问题 是 : 很 容易 将 不 成 熟 的 代码 融入 共享 的 版 本 库 ， 和 破坏 共 
齐 版 本 库 相 应 分 文 的 代码 稳定 性 。 例 如 破坏 编译 、 破 坏 每 日 集成 。 这 是 
因为 开发 者 殉 隆 版 本 库 后 ， 直 接 工 作 在 默认 的 跟 踊 分 文 上 ， 当 不 小 心 执 
行 git push 命 令 时 ， 婚 会 将 目 己 的 提交 推送 到 服务 右上 。 


为 了 避免 上 上面 的 问题 ， 开 发 者 可 能 会 延迟 推送 ， 在 软件 开 及 的 整个 
过 程 中 《例如 一 个 月 ) 只 在 本 地 提交 ， 而 不 同 服 务 器 推送 ， 这 样 会 产生 
更 严重 的 问题 : 数据 丢失 。 开 及 者 可 能 因为 操作 系统 感染 病毒 ， 或 者 不 
小 心 删除 目录 ， 或 者 硬盘 故障 导致 工作 成 果 的 彻底 丢失 ， 这 对 个 人 和 团 
队 来 说 都 是 灾难 。 


解决 这 个 问题 的 方法 也 很 简单 ， 束 是 在 本 地 创建 本 地 分 文 〈 功 能 分 


文 ) ， 并 且 同 时 在 服务 需 端 〈 共 吝 版 本 库 ) 也 创建 自己 独 齐 的 功能 分 
文 。 本 地 提交 推送 到 共 孚 版 本 库 中 目 己 独 理 的 分 文 上 。 当 开发 完成 之 
后 ， 将 功能 分 文 合并 到 主线 上 ， 推 送 到 共享 版 本 库 ， 完 成 开发 。 当 然 如 
果 不 再 需要 该 特性 分 文 时 就 要 做 些 清理 工作 。 参 见 图 21-3 所 示 的 工作 流 
程 图 。 














git checkout 
-b My/Branch 


My/Branch 分 支 


git push 
origin 
My/Branch 
















git push 








WE sosoooroososoooooososssoso 
A | 





a git pull 






ee it fetch | 
origin :origin master git fetch 
:My/Branch : 


git merge git rebase 
orlgin/master origin/master 


git mergetool 










git branch 
-d My/Branch 








git pull 


git checkout git push origin 
master My/Branch:master 


图 21-3 集中 式 协 同 模型 工作 流 2 


21.1.2 ”Gerrit 特 殊 的 集中 式 协 同 模 型 


1. 传 统 集中 式 协同 模型 的 缺点 


传统 集中 式 协 同 模型 的 主要 问题 是 在 管理 上 : 谁 能 够 同 版 本 库 推 
送 ? 可 以 信赖 菏 人 问 版 本 库 推 送 吗 ? 


对 于 在 一 个 相对 固定 的 团队 内 部 使 用 集中 式 协 同 模型 没有 问题 ， 因 
为 大 家 彼此 信赖 ， 都 熟悉 项 目的 相关 领域 。 但 是 对 于 公开 的 项 目 《开源 
项 目 ) 来 说 ， 采 用 集中 式 的 协同 模型 ， 必 然 只 能 有 部 分 核心 人 员 具 
有 “ 写 ” 权 限 ， 很 多 有 能 力 的 参与 者 会 被 拒 之 门 外 ， 这 不 利于 项 目的 友 
展 。 因 此 集中 式 协 同 模型 主要 应 用 在 公司 范围 内 和 商业 软件 开发 中 ， 而 
不 会 成 为 开源 项 目的 首选 。 











2. 强 制 代码 审核 的 集中 式 协 同 模型 


Android 项 目 采 用 了 独树一帜 的 集中 式 管 理 模 型 一 一 通过 Gerrit 架 设 
的 审核 服务 器 对 提交 进行 强制 审核 。Android 是 由 近 200 个 Git 版 本 库 组 成 
的 庞大 的 项 目 ， 为 了 对 庞大 的 版 本 库 进 行 管理 ，Android 项 目 开 发 了 两 
个 工具 repo 和 Gerrit 进 行 版 本 库 的 管理 。 其 中 Gerrit 服 务 器 为 Android 项 目 
引入 了 特别 的 集中 式 协同 模型 。 





Gerrit 服 务 器 通过 SSH 协 议 管理 Git 版 本 库 ， 并 实现 了 一 个 Web 界 面 
的 评审 工作 流 。 任 何 注册 用 户 都 可 以 参与 到 项 目 中 来 ， 都 可 以 将 Git 提 
交 推 送 到 Gerrit 管 理 下 的 Git 版 本 库 〈 通 过 Gerrit 启 动 的 特殊 SSH 端 口 ) 。 
Git 推 送 不 能 直接 推送 到 分 支 ， 而 是 推送 到 特殊 的 引用 refs/for<branch- 


name>， 此 提交 会 自动 转换 为 形 如 refs/changes/<nn>/<review-id>/<patch- 
set> 的 补丁 集 ， 此 补丁 集 在 Gerrit 的 Web 界 面 中 显示 为 对 应 的 评审 任务 。 
评审 任务 进入 审核 流程 ， 通 过 相关 负责 人 的 审核 后 才 被 接受 ， 并 合并 到 
正式 的 版 本 库 中 。 





本 书 的 第 5 篇 第 32 章 会 详细 介绍 Gerrit 代 码 审 核 服务 器 的 部 署 和 使 


21.2 ”社交 网 络 式 协同 模型 





自从 分 布 式 版 本 库 控制 系统 (Mercuria/Hg、Bazaar、Git 等 ) 诞生 
之 后 ， 有 越 来 越 多 的 开源 项 目 迁 移 了 版 本 控制 系统 ， 例 如 从 Subversion 
或 CVS 迁 移 到 分 布 式 版 本 控制 系统 。 因 为 众多 的 开源 项 目 逐 渐 认 识 到 ， 
集中 式 的 版 本 控制 管理 方式 阻止 了 更 多 的 人 参与 项 目的 开发 ， 对 项 目的 
发 展 不利 。 


集中 式 版 本 控制 系统 的 最 大 问题 是 ， 如 果 没 有 在 服务 句 端 授权 ， 葱 
无 法 提交 ， 也 就 无 法 保存 上 自己 的 更 改 。 开 源 项 目 虽 然 允许 所 有 人 访问 代 
码 库 ， 但 是 不 可 能 授权 “ 写 操作 ?给 所有 的 人 ， 人 否则 代码 质量 无 法 控制 
(Gerrit 审 核 服 务 占 是 例外 )〉 。 与 此 相对 照 的 是 ， 在 使 用 了 分 布 式 版 本 
控制 系统 之 后 ， 任 何人 都 可 以 在 本 地 克隆 一 个 和 远程 版 本 库 一 模 一 样 的 
版 本 库 ， 本 地 的 版 本 库 允 许 任何 操作 ， 这 就 极 大 地 调动 了 开发 者 投入 项 
目 研 究 的 积极 性 。 











分 布 式 的 开发 必然 带 来 协同 的 问题 ， 如 何 能 够 让 一 个 素 不 相识 的 开 
发 者 将 他 的 页 献 提交 到 项 目 中 ? 如 何 能 够 最 大 化 地 发 动 和 汇聚 全 球 的 智 
芒 ? 开 源 社 区 逐渐 发 展 出 金字 塔 状 社交 网 络 式 协同 模型 (如 图 21-4 所 
示 ) ， 而 这 也 是 必然 之 选 。 





共享 的 版 本 库 





核心 开发 者 





开发 者 开发 者 


开发 者 开发 者 开发 者 


图 21-4 金字 塔 状 社交 网 络 式 协同 模型 


社交 网 络 的 含义 是 针对 版 本 库 的 修改 在 信任 的 个 体 〈 程 序 员 ) 间 传 
递 。 金 字 塔 的 含义 是 ， 虽 然 理论 上 每 个 开发 者 的 版 本 库 都 是 平等 的 ， 但 
会 有 一 个 公认 的 权威 的 版 本 库 ， 这 个 版 本 库 由 一 个 或 多 个 核心 开发 者 
责 维护 〈 具 有 推送 的 权限 ) 。 核 心 的 开发 人 员 负 责 审核 其 他 贡献 者 的 
提交 ， 审 核 可 以 通过 邮件 传递 的 补丁 或 访问 (PULL) 贡献 者 开放 的 代 
码 库 进行 。 由 此 构成 了 以 核心 开发 团队 为 顶层 的 、 所 有 贡献 者 共同 参与 
的 金字 塔 状 开发 者 社交 网 络 。 





Linux 社 区 束 是 典型 的 金字 塔 结构 。Linus Torvalds 的 版 本 库 是 公认 
的 官方 版 本 库 ， 人 允许 核心 成 员 的 提交 。 其 他 贡献 者 的 提交 必须 经 过 一 个 
或 多 个 核心 成 员 的 审核 后 ， 才 能 经 由 核心 成 员 代 为 推送 到 官方 版 本 库 。 





采用 这 种 金字 塔 状 社交 网 络 式 协 同 模型 不 需要 复杂 的 Git 服 务 器 设 
再 要 项 目 管理 者 提供 一 个 让 其 他 人 只 读 访 问 的 版 本 库 即 可 。 当 然 
管理 者 要 能 够 通过 茶 种 方法 回 该 版 本 库 推送 ， 以 便 其 他 人 能 够 通过 该 版 


21.2.1 页 献 者 开放 只 读 版 本 库 


因为 不 能 直接 向 项 目 只 读 共享 的 版 本 库 提 交 ， 为 了 能 让 项 目的 管理 
者 获取 自己 的 提交 ， 贡 献 者 需要 提供 项 目 管理 者 访问 自己 版 本 库 的 方 
法 。 建 立 一 个 自己 拥有 的 只 读 共享 版 本 库 是 一 个 简单 易 行 的 方法 。 第 5 
篇 "搭建 Git 服 务 器 ”的 相关 章节 会 介绍 几 种 快速 搭建 只 读 Git 版 本 库 的 方 
法 ， 包 括 : 用 HTTP 智 能 协议 搭建 Git 服 务 器 ， 用 Git 协 议 搭建 Git 服 务 
妖 。 

















页 献 者 建立 自己 的 只 读 共享 版 本 库 后 ， 需 要 检查 和 整理 自己 页 献 的 
提交 ， 检 查 项 目 如 下 : 


` 页 献 的 提交 要 处 于 一 个 单独 的 特性 分 支 中 ， 并 且 要 为 该 特性 分 支 
取 一 个 有 意义 的 名 字 。 


使 用 贡献 者 的 名 字 及 简单 的 概括 性 文字 是 非常 好 的 特性 分 文 名 。 例 
如 对 我 来 说 可 能 创建 名 为 jiangxin/fix-bug-xxx 的 分 支 。 


` 页 献 的 提交 是 否 基 于 上 游 对 应 分 支 的 最 新 提交 ? 如 果 不 是 ， 需 要 
变 基 到 上 游 最 新 提交 ， 以 免 产生 合并 。 











项 目的 管理 者 会 尽量 避免 不 必要 的 合并 ， 因 此 会 要 求 页 献 者 的 提交 
尽量 基于 项 目的 最 新 提交 来 进行 。 使 用 下 面 的 方式 建立 跟踪 远程 分 支 的 
本 地 分 支 ， 可 以 很 简单 地 实现 在 执行 git pull 操 作 时 使 用 变 基 操作 取代 合 
并 操作 。 




















$ git checkout -b jiangxin/fix-bug-xxx origin/master 
$ git config branch.jiangxin/fix-bug-xxx.rebase true 
hack, hack, hack 

$ git pull 





然后 贡献 者 就 可 以 癌 项 目 管理 者 发 送 通知 邮件 ， 告 诉 项 目 管理 者 有 
新 贡献 的 代码 等 待 他 的 审核 。 邮 件 中 大 致 包 括 以 下 内 容 : 


` 为 什么 要 修改 项 目的 代码 。 
相应 的 修改 是 否 经 过 了 测试 ， 或 者 提交 中 是 否 包含 了 单元 测试 。 
-自己 版 本 库 的 访问 地 址 。 


特性 分 支 的 名 称 。 


Git 提 供 了 一 个 名 为 git request-pull 的 命令 ， 可 以 非常 方便 地 生成 上 


YI 人 
述 信 息 。 


21.2.2 ”以 补丁 方式 贡献 代码 





使 用 补丁 文件 方式 贡献 代码 也 是 开源 项 目 常 用 的 协同 方式 。Git 项 
目 本 吴 就 是 采用 该 方式 运作 的 。 运 作 方 式 如 下 : 


(1) 每 个 用 户 先 在 本 地 版 本 库 修改 代码 。 


(2) 修改 完成 后 ， 通 过 执行 git format-patch 命 令 将 提交 转换 为 补 


(3) 如 果 提 交 很 多 且 比较 杂乱 ， 可 以 考虑 使 用 StGit 对 提交 进行 重 





(4) 调用 git send-email 命 令 ， 或 者 通过 图 形 界面 的 邮件 客户 端 软 件 
将 补丁 发 给 邮件 列表 及 项 目 维护 者 。 


(5) 项 目 维护 者 认可 页 献 者 提交 的 补丁 后 ， 执 行 git am 命令 应 用 补 


第 3 篇 的 “第 20 章 ”补丁 文件 交互 ”已经 详细 介绍 了 该 模式 的 工作 流 
程 ， 请 参考 相关 章节 


第 22 革 Topgit 协 同 模型 


如 果 没 有 Topgit1! 1 ， 就 不 会 有 此 书 。 因 为 发 现 了 Topgit， 我 才 下 定 
决心 在 公司 大 范围 推广 Git， 因 为 Topgit 才 激发 了 我 对 Git 的 好 奇 之 心 。 


[1] http:/ /repo.or.cz/w/topgit.git 


22.1 作者 版 本 控制 系统 的 三 个 里 程 碑 


1.Subversion 和 卖主 分 支 


从 2005 年 开始 我 专心 于 开源 软件 的 研究 、 定 制 开 发 和 整合 ， 在 这 之 
后 的 几 年 ， 一 直 使 用 Subversion 做 版 本 控制 。 对 于 定制 开发 工作 ， 
Subversion 有 一 种 称 为 卖主 分 文 〈(Vendor Branch) 的 模式 。 


卖主 分 支 的 工作 模式 如 图 22-1 所 示 : 


vy2.0 v3.0 





vi.0 cl c2 M1 c3 c4 c98 c99 M2 


图 22-1 卖主 分 支 工 作 模式 图 


` 图 22-1 由 左 至 右 ， 提 交 随 着 时 间 而 递增 。 


` 主线 ttunk 用 于 对 定制 开发 的 过 程 进行 跟踪 。 


` 主线 的 第 一 个 提交 v1.0 是 导入 上 游 ( 该 开源 软件 的 官方 版 本 库 ) 
发 布 的 版 本 。 


. 之 后 在 v1.0 提 交 之 处 建立 分 支 ， 是 为 卖主 分 支 (vendor 


branch) 。 

` 主线 上 依次 进行 了 c1、c2 两 次 提交 ， 是 基于 v1.0 进 行 的 定制 开 
发 。 

.上游 有 了 新 版 本 ， 提 交 到 卖主 分 支 上 ， 即 v2.0 提 交 。 和 v1.0 相 比 


除了 大 量 的 文件 更 改 外 ， 还 可 能 有 文件 增加 和 删除 。 


` 然后 在 主线 上 执行 从 卖主 分 支 到 主线 的 合并 ， 即 提交 M1。 因 为 


此 时 主线 上 的 改动 相对 较 少 ， 合 并 v2.0 并 不 太 费 事 。 


. 主线 继续 开发 。 可 能 同时 有 针对 不 同 需求 的 定制 开发 ， 在 主线 上 
会 有 越 来 越 多 的 提交 ， 如 上 图 从 c3 到 c99 的 近 百 次 提交 。 


. 如 果 在 卖主 分 支 上 导入 上 游 的 新 版 本 v3.0， 合 并 将 会 非常 痛苦 。 
因为 主线 上 针对 不 同 需求 的 定制 开发 已 经 混杂 在 一 起 了 ! 
实践 证 明 ，Subversion 的 卖主 分 文 对 于 大 规模 的 定制 开发 非常 不 适 


合 。 回 上 游 新 版 本 的 迁移 会 随 着 定制 功能 和 提交 的 增多 变 得 越 来 越 困 
难 。 





2.Hg 和 MQ 


在 2008 年 ， 我 们 的 版 本 库 迁 移 到 Mercurial (水 银 ， 又 称 为 Hg) ， 并 
工作 在 “Hg+MQ” 模 式 下 ， 我 自 以 为 找 到 了 定制 开发 版 本 控制 的 终极 解 


决 方案 ， 那 时 我 们 已 被 Subversion 的 卖主 分 支 折磨 得 太 久 了 。 


Hg 和 Git 一 样 也 是 一 种 分 布 式 版 本 控制 系统 ，MQ 是 Hg 的 一 个 扩 
展 ， 可 以 实现 提交 和 补丁 两 种 模式 之 间 的 转换 。Hg 版 本 库 上 的 提交 可 
六 通过 hg qimport 命 令 转 化 为 补丁 列表 ， 也 可 以 通过 hg qpush、hg qpop 
等 命令 在 补丁 列表 上 游 移 〈 出 栈 和 入 栈 ) ， 入 栈 的 补丁 转化 为 Hg 版 本 
库 的 提交 ， 补 丁 出 栈 会 从 Hg 版 本 库 移 走 最 新 的 提交 。 


江 








相 比 Subversion 的 卖主 分 文 ， 使 用 “Hg+MQ” 的 好 处 在 于 : 


. 针对 不 同 需求 的 定制 开发 ， 其 提交 被 限定 在 各 自 独 立 的 补丁 文件 
中 而 不 会 混杂 在 一 起 。 


. 针对 同一 个 需求 的 定制 开发 ， 无 论 多 少 次 的 更 改 都 体现 为 补丁 广 
件 的 变化 ， 而 补丁 文件 本 身 也 是 被 版 本 控制 的 。 


` 各 个 补丁 之 间 是 顺序 依赖 关系 ， 形 成 一 个 Quilt 格 式 的 补丁 列表 。 


“ 向 上 游 新 版 本 迁移 过 程 的 工作 量 降 低 了 ， 除 了 因为 针对 各 个 功能 
的 定制 开发 被 隔离 ， 还 有 迁移 过 程 也 非常 具有 可 操作 性 。 


将 定制 开发 迁移 至 上 游 新 版 本 的 过 程 是 ， 先 将 所 有 补 J“ 出 栈 *"， 下 
将 上 游 新 版 本 提交 到 主线 ， 然 后 依次 将 补 J“ 入 栈 ”*"。 如 果 上 游 新 版 本 的 
代码 改动 较 大 ， 补 丁 入 栈 可 能 会 遇 到 冲突 ， 在 冲突 解决 完毕 后 执行 hg 
qref 命 令 即 可 完成 定制 开发 到 新 的 上 游 版 本 的 迁移 。 








但 是 如 果 需 要 在 定制 开发 上 进行 多 人 协作 ,，“Hg+MQ” 的 星 病 就 显 
现 了 。 因 为 "Hg+MQ" 工 作 模式 下 ， 定 制 开发 的 成 果 是 一 个 补丁 库 ， 在 
补丁 库 上 进行 协作 的 难度 非常 大 ， 当 发 生 神 突 的 时 候 ， 补 丁 文件 本 刁 的 
冲突 会 让 人 眼花 乱 。 这 如 引 及 了 我 们 第 三 次 版 本 控制 系统 大 迁移 。 





3.Git 和 Topgit 


2009 年 ， 我 们 把 目光 锁定 在 Topgit 上 。Topgit 是 Topic Git 的 简写 ， 是 
用 shell 脚 本 语言 开发 的 辅助 工具 ， 对 Git 功 能 进行 了 扩展 ， 用 于 管理 特性 
分 支 的 开发 。Topgit 为 特性 分 支 引 入 了 基准 分 支 的 概念 ， 并 以 此 管理 特 
性 分 支 间 的 依赖 ， 让 特性 分 支 向 上 游 新 版 本 的 迁移 变 得 非常 简单 。 


Topgit 的 主要 特点 有 : 


上 游 的 原始 代码 位 于 开发 主线 (mastet 分 支 ) ， 而 每 一 个 定制 开 
发 都 对 应 于 一 条 Git 特 性 分 支 (refs/heads/t/feature name) 。 


` 特性 分 支 之 间 的 依赖 关系 不 像 “Hg+MQ 那样 是 逐一 依赖 模 
式 ， 而 是 可 以 任意 设 定 分 支 之 间 的 依赖 : 多 重 依赖 、 平 行 依赖 等 。 


特性 分 支 和 其 依赖 的 分 支 可 以 导出 为 Quilt 格 式 的 补丁 列表 。 


. 因为 针对 某 一 需求 的 定制 开发 限定 在 特定 的 特性 分 支 中 ， 可 以 多 
人 协同 参与 ， 和 正常 的 Git 开 发 别 无 二 致 。 


22.2 Topgit 原 理 


图 22-2 是 一 个 近似 的 Topgit 实 现 图 〈 略 去 了 重要 的 top-bases 分 
3 


(特性 分 支 B: refs/heads/t/B) 


(特性 分 支 A: refs/heads/t/A) 
(主线 /卖主 分 支 : master) 


(特性 分 支 C: refs/heads/t/C) 





图 22-2 ”Topgit 特 性 分 支 关 系 图 


在 图 22-2 中 ， 主 线 上 的 v1.0 是 上 游 版 本 的 一 次 提交 。 特 性 分 文 A 和 C 
都 直接 依赖 主线 master， 而 特性 分 支 B 则 依赖 特性 分 文 A。 提 交 M1 是 特 
定 分 文 B 因 为 特性 分 文 A 更 新 而 做 的 一 次 迁移 。 提 交 M2 和 M4 则 分 别 是 特 
性 分 支 A 和 C 因 为 上 游 出 现 了 新 版 本 v2.0 而 做 的 迁移 。 当 然 特性 分 支 B 也 
要 做 相应 的 迁移 ， 是 为 M3。 


上 述 的 图 示 非 营 粗 糙 ， 因 为 如 果 按 照 这 样 的 设计 很 难 将 特性 分 文 导 
出 为 补丁 文件 。 例 如 特性 分 文 B 导 出 为 补丁 ， 实 际 上 应 该 是 M2 和 M3 之 
间 的 差异 ， 而 绝 不 是 a2 和 M3 之 间 的 差异 。Topgit 为 了 能 够 实现 将 分 文 导 





出 为 补丁 ， 又 为 每 个 特性 的 开发 引入 了 一 个 特殊 的 引用 (refs/top- 
bases/* ) ， 用 于 追踪 特性 分 支 的 “ 变 基 ”， 称 为 特性 分 文 的 基准 分 文 。 所 
有 特性 分 文 的 基准 分 文 也 形成 了 复杂 的 分 文 天 系 图 ， 如 岁 22-3 所 示 。 


(特性 B 的 茜 淮 分 支 : refs/top-bases/t/B) 
(特性 A 的 基准 分 支 : refs/top-bases/t/A) 


(主线 /或 主 分 文 : master) 





(特性 C 的 某 准 分 支 : refs/top-bases/t/C) 
图 22-3 Topsit 特 性 分 支 的 基准 分 支 关 系 图 


把 图 22-2 和 图 22-3 两 张 分 文 图 重合 ， 重 合 点 之 间 的 差异 就 可 用 于 将 
特性 分 支 导 出 为 补丁 文件 。 





上 面 的 特性 分 文 B 还 只 是 依赖 一 个 分 文 ， 如 打出 现 一 个 分 文 依赖 多 
个 特性 分 文 的话 ， 情 况 束 会 更 加 复杂 ， 也 更 能 体现 出 这 种 设计 方案 的 精 


妙 。 





Topgit 还 在 每 个 特性 分 支 工作 区 的 根 目 录 引 入 两 个 文件 ， 用 于 记录 
分 文 的 依赖 及 关于 此 分 支 的 说 明 : 


* 文件 .topdeps 记 录 该 分 支 所 依赖 的 分 支 列表 。 


该 文件 通过 tg create 命 令 在 创建 特性 分 文 时 目 动 创建 ， 或 者 通过 tg 


depend add 命 令 来 添加 新 依赖 。 
` 文件 .topmsg 记 录 该 分 支 的 描述 信息 。 


该 文件 通过 tg create 命 令 在 创建 特性 分 文 时 创建 ， 可 以 手动 编辑 。 


22.3 Topgit 的 安装 


Topgit 用 shell 脚 本 语言 开发 ， 可 以 安装 在 所 有 的 类 Unix 环 卉 中 ， 例 
如 Linux、Mac OS XX， 以 及 Windows 下 的 Cygwin。 下 面 的 官方 网 站 链接 
介绍 了 Topgit 的 安装 和 使 用 方法 : http://repo.or.cz/w/topgit.git?a=blob ; 
f=README.。 


1.Linux 下 安装 Topgit 





安装 官方 的 Topgit 版 本 ， 直 接 殉 隆 官方 的 版 本 库 ， 执 行 make 即 可 : 





$ git clone git://repo.or.cz/topgit.git 
$ cd topgit 

$ make 

$ make install 





默认 会 把 Topgit 的 可 执行 文件 tg 安装 在 $bHOME/bin( 用 户主 目录 下 
的 bin 目 录 ) 下 ， 如 果 没 有 将 ~/bin 加 入 环境 变量 $8PATH 中 ， 就 可 能 无 法 


执行 tg 命令 。 








如 果 有 具有 root 权 限 ， 可 以 在 编译 和 安装 时 间 make 命 令 传递 prefix 变 
量 ， 将 Topgit 安 装 在 系统 目录 中 。 





$ make prefix=/usr 
$ sudo make prefix=/usr install 





我 对 Topgit 做 了 一 些 增强 和 改进 品 ， 在 后 面 的 章节 将 予以 介绍 。 如 
果 想 安装 改进 后 的 版 本 ， 需 要 预先 安装 Quilt 补 丁 管 理工 具 ， 然 后 进行 如 
下 操作 。 





$ git clone git://github.com/ossxp-com/topgit.git 
$ cd topgit 

$ QUILT_PATCHES=debian/patches quilt push -a 

$ make prefix=/usr 

$ sudo make prefix=/usr install 





如 果 用 的 是 Ubuntu 或 Debian Linux 操 作 系 统 ， 还 可 以 这 么 安装 。 


(1) 先 安装 Debian/Ubuntu 打 包 依 赖 的 相关 工具 软件 。 





$ sudo aptitude install quilt debhelper \ 
build-essential fakeroot dpkg-dev 





(2) 再 调用 dpkg-buildpackage 命 令 ， 编 译 出 DEB 包 ， 再 安装 。 





$ git clone git://github.com/ossxp-com/topgit.git 
$ cd topgit 

$ dpkg-buildpackage -b -rfakeroot 

$ sudo dpkg -i ../topgit_*.deb 





(3) 安装 完毕 后 ， 重 新 加 载 命 令 行 补 齐 ， 可 以 更 方便 地 使 用 tg 命 





$ . /etc/bash_completion 





2.Mac OS X 下 安装 Topgit 





在 Mac OS X 下 安装 官方 版 本 的 Topgit， 在 使 用 中 会 遇 到 各 种 各 样 的 
问题 。 这 是 因为 Mac OS X 下 部 分 shell 命 令 的 行为 和 相应 的 GNU 命 令 的 
行为 不 一 致 ， 例 如 echo、paste 和 sed 命 令 等 。 


在 Mac OS X 下 可 以 使 用 Homebrew 安 装 所 需 的 GNU 工 具 。 如 下 : 





$ brew install gnu-sed 
$ brew install quilt 





然后 别 筷 了 安装 改造 后 的 Topgit。 





$ git clone git://github.com/ossxp-com/topgit.git 
$ cd topgit 

$ QUILT_PATCHES=debian/patches quilt push -a 

$ make prefix=/usr 

$ sudo make prefix=/usr install 





3.Windows 下 安装 Topgit 


Windows 下 的 msysGit 因 为 缺乏 Topgit 依 赖 的 命令 行 工 具 (如 fgrep、 
install、make、mkfifo、mktemp、tsort 等 ) ， 和 安装 和 运行 Topgit 会 过 到 
难 。 从 安装 好 的 MSYS 中 或 MSYS-CN 中 中 提取 所 需要 的 软件 到 msysGit 
环境 中 ， 可 以 实现 Topgit 在 msysGit 中 的 安装 和 运行 。 


Windows 下 的 Cygwin 拥 有 一 个 完整 的 POSIX 环 境 ， 当 安装 了 所 需 的 
工具 (make、gquilt! 人 和 等) 后， 就 可 以 正常 地 编译 和 使 用 Topgit。 


注意 如 果 殉 隆 Topgit 版 本 库 后 工作 区 文件 的 换行 符 是 DOS 格 式 换 行 





符 (CRLF)〉， 在 安装 过 程 中 会 遇 到 麻烦 。 元 隆 改 进 的 Topgit 则 不 会 出 现 
类 似 问 题 ， 这 是 因为 在 工作 区 根 目录 下 存在 一 个 .gitattributes | 文件 ， 
可 以 保证 检 出 的 工作 区 文件 采用 Unix 格 式 的 换行 符 (LF)》。 





在 Cygwin 下 安装 改进 后 的 Topgit 使 用 如 下 方法 : 





$ git clone git://github.com/ossxp-com/topgit.git 
$ cd topgit 

$ QUILT_PATCHES=debian/patches quilt push -a 

$ make prefix=/usr 

$ make prefix=/usr install 





[1 ”我 对 Topgit 的 改进 采用 了 Topgit 的 开发 模式 ， 如 果 大 家 发 现 我 的 改动 
没有 及 时 地 跟 上 上 游 代码 ， 用 户 可 以 自行 使 用 Topgit 将 改动 迁移 到 最 新 
的 上 游 版 本 。 还 要 提醒 的 是 ， 不 要 把 我 的 错误 算 到 上 游 开 发 者 头 上 。 

[2] http:/ /www.mingw.org/ wiki/msys 

[3] http://code.google.com/p/msys-cn/ 

团 如 果 要 安装 改进 后 的 Topgit。 


[5] 参见 第 8 篇 第 40 章 “40.3 换 行 符 问 题 ”。 


22.4 Topgit 的 使 用 
通过 前 面 的 原理 部 分 ， 可 以 发 现 Topgit 为 管理 特性 分 支 所 引入 的 配 
置 文件 和 基准 分 支 都 是 和 Git 兼 容 的 。 


* 在 refs/top-bases/ 命 名 空间 下 的 引用 ， 用 于 记录 特性 分 支 的 基准 分 


` 在 特性 分 支 的 工作 区 根 目录 下 引入 两 个 文件 .topdeps 和 .topmsg， 
用 于 记录 分 支 的 依赖 和 说 明 。 


. 引入 新 的 钩子 脚本 hooks/pte-commit， 用 于 在 提交 时 检查 分 支 依 
赖 有 没有 发 生 循环 等 。 


Topgit 的 命令 行 的 一 般 格式 为 : 





tg [global option] <subcmd> [command_options...] [arguments...] 








说 明 ， 在 子 命令 前 的 全 局 选项 ， 目 前 可 用 的 只 有 -r<remote>， 用 于 
设 定 远程 版 本 库 ， 默 认为 origin。 在 子 命令 后 可 以 跟 子 命令 相关 的 参 
数 。 





下 面 就 来 介绍 Topgit 常 用 的 子 命令 。 


1.tg help 命 令 


tg helpf HP 命令 显示 帮助 信 已.,。 在 tg help 后 面 提 供 子 命 令 名 称 ， 可 以 获 
得 该 子 命令 详细 的 帮助 信息 。 


2.tg create 命 令 


tg create 命 令 用 于 创建 新 的 特性 分 文 。 用 法 如 下 : 





tg [...] create NAME [DEPS,...|-r RNAME] 





其 中 : 


" NAME 是 新 的 特性 分 支 的 分 支 名 ， 必 须 提 供 。 一 般 约定 俗 成 : 
NAME Wt/ 前 级 开头 的 表明 此 分 支 是 一 个 Topgit 特 性 分 支 


DEPS... 是 可 选 的 一 个 或 多 个 依赖 分 支 名 。 如 果 不 提 供 依 赖 分 支 
名 ， 则 使 用 当前 分 支 作为 新 的 特性 分 支 的 依赖 分 支 。 


. -fr RNAME 选 项 ， 将 远程 分 支 作为 依赖 分 支 ， 不 常用 


tg create 命 令 会 创建 新 的 特性 分 文 refs/heads/NAME， 以 及 特性 分 文 
的 基准 分 支 refs/top-bases/INAME， 并 且 在 项 目 根 目 录 下 创建 文件 .topdeps 
和 .topmsg。 还 会 提示 用 户 编辑 .topmsg 文 件 ， 输 入 详细 的 特性 分 支 描述 


主 自 


品 ,Do 


为 了 试验 Topgit 命 令 ， 找 一 个 示例 版 本 库 或 干脆 创建 一 个 版 本 库 。 
在 示例 版 本 库 的 master 分 文 下 输入 如 下 命令 创建 一 个 名 为 Vfeaturel 的 特 
性 分 支 : 





$ tg create t/featurel1 

tg: Automatically marking dependency on master 

tg: Creating t/featurel1 base from master... 

Switched to a new branch 't/featurel' 

tg: Topic branch t/featurel1 set up. Please fill] .topmsg now and make initial commit ， 
tg: To abort: git rm -f .top* && git checkout master && tg delete t/featurel1 





提示 信息 中 以 “tg:* 开 头 的 是 Topgit 产 生 的 说 明 。 其 中 提示 用 户 编 
辑 .topmsg 文 件 ， 然 后 执行 一 次 提交 操作 完成 Topgit 特 性 分 文 的 创建 。 


如 有 果 想 撤销 此 次 操作 ， 删 除 项 目 根 目录 下 的 .top* 文 件 ， 切 换 到 
master 分 支 ， 然 后 执行 tg delete t/feature1l 命 令 删 除 t/featurel 分 支 及 特性 分 


支 的 基准 分 支 refs/top-bases/t/feature1。 


输入 git status 可 以 看 到 当前 已 经 切换 到 Ufeature1 分 文 ， 并 且 Topgit 已 
经 创建 了 .topdeps 和 .topmsg 文 件 ， 并 已 将 这 两 个 文件 加 入 到 和 暂 存 区 。 





$ git status 
# On branch t/featurel 
# Changes to be committed: 


# (use "git reset HEAD <file>..." to unstage) 
## 

# new file: .topdeps 

# new file: .topmsg 

# 


$ cat ,topdeps 
master 





打开 .topmsg 文 件 ， 会 看 到 下 面 的 内 容 《〈 前 面 增加 了 行 号 ) : 


| 


From: Jiang Xin <jiangxin@ossxp.com> 
Subject: [PATCH] t/featurel 


<patch description> 


OODP 


Signed-off-by: Jiang Xin <jiangxin@ossxp.com> 





其 中 第 2 行 是 关于 该 特性 分 文 的 简短 描述 ， 第 4 行 是 详细 描述 ， 可 以 


编辑 完成 ， 别 态 了 提交 ， 提 交 之 后 才 完 成 Topgit 分 支 的 创建 。 





$ git add -u 
$ git commit -m "create tg branch t/featurel1" 





如 果 这 时 想 创 建 一 个 新 的 特性 分 支 Vfeature2， 并 且 也 是 要 依赖 
master， 注 意 需 要 在 命令 行 中 提供 master 作 为 第 二 个 参数 ， 以 设 定 依赖 
分 文 。 因 为 当前 所 处 的 分 支 为 Vfeature1， 如 果 不 提供 指定 的 依赖 分 支 就 
会 目 动 依赖 当前 分 文 。 





$ tg create t/feature2 master 
$ git commit -m "create tg branch t/feature2" 





下 面 的 命令 将 创建 t/feature3 分 支 ， 该 分 支 依赖 Vfeaturel 和 


t/feature2。 





$ tg create t/feature3 t/featurel1 t/feature2 
$ git commit -m "create tg branch t/feature3" 





3.tg info 命 令 





tg info 命 令 用 于 显示 当前 分 支 或 指定 的 Topgit 分 支 的 信息 。 用 法 如 
下 : 





tg [...] info [NAME] 





其 中 NAME 是 可 选 的 Topgit 分 支 名 。 例 如 执行 下 面 的 命令 会 显示 分 
支 t/feature3 的 信息 : 





$ tg info 
Topic Branch: t/feature3 (1/1 commit) 
Subject: [PATCH] t/feature3 
Base: 0fa79a5 
Depends: t/featurel 
t/feature2 
Up-to-date. 





切换 到 t/featurel 分 支 ， 做 一 些 修 改 并 提交 : 





$ git checkout t/featurel1 

$ echo Hi > hacks .txt 

$ git add hacks.txt 

$ git commit -m "hacks in t/featurel1." 





然后 再 来 看 t/feature3 的 状态 : 





$ tg info t/feature3 
Topic Branch: t/feature3 (1/1 commit) 
Subject: [PATCH] t/feature3 
Base: 0fa79a5 
Depends: t/featurel 
t/feature2 
Needs update from: 
t/featurei1 (1/1 commit ) 





状态 信息 显示 tfeature3 不 再 是 最 新 的 状态 〈Up-to-date) ， 因 为 依赖 


的 WVfeaturel 分 支 包含 新 的 提交 ， 而 需要 从 tfeaturel 获 取 更 新 。 
4.tg update 命 令 


tg update 命 令 用 于 更 新 分 文 ， 即 从 依赖 的 分 支 获 取 最 新 的 提交 合并 
到 当前 分 支 。 同 时 在 refs/top-bases/ 命 名 空间 下 的 特性 分 支 的 基准 分 文 也 
会 更 新 。 








tg [...] update [NAME] 





其 中 NAME 是 可 选 的 Topgit 分 支 名 。 下 面 束 对 需要 更 新 的 t/feature3 


分 支 执 行 tg update 命 令 。 





$ git checkout t/feature3 

$ tg update 

tg: Updating base with t/featurei changes... 

Merge made by recursive. 
hacks.txt | 于 二 
1 files changed, 1 insertions(+), 0 deletions(-) 
create mode 100644 featurel 

tg: Updating t/feature3 against new base... 

Merge made by recursive. 
hacks.txt | 业 秆 
1 files changed, 1 insertions(+), 0 deletions(-) 
create mode 100644 featurel1 





从 上 面 的 输出 信息 可 以 看 出 执行 了 两 次 分 文 合 并 操作 ， 一 次 是 针对 
refs/top-bases/tfeature3 引 用 指 回 的 特性 分 文 的 基准 分 文 ， 另 外 一 次 针对 
的 是 refs/heads/t/feature3 特 性 分 支 。 


执行 tg update 命 令 因 为 要 涉及 分 文 的 合并 ， 因 此 并 非 每 次 都 会 成 


功 。 例 如 在 t/feature3 和 tfeaturel 中 同时 对 同一 个 文件 (如 hacks.txt) 进 
行 修改 。 然 后 在 Ufeature3 中 再 执行 tg update 可 能 束 会 报错 ， 进 入 冲突 解 
决 状态 。 





$ tg update t/feature3 
tg: Updating base with t/featurei changes... 
Merge made by recursive. 
hacks.txt | 1+ 
1 files changed, 1 insertions(+), 0 deletions(-) 
tg: Updating t/feature3 against new base... 
Auto-merging hacks.txt 
CONFLICT (content): Merge conflict in hacks.txt 
Automatic merge failed; fix conflicts and then commit the result. 
tg: Please commit merge resolution. No need to do anything else 
tg: You can abort this operation using ‘git reset --hard now 
tg: and retry this merge later using ‘tg update . 





可 以 看 出 第 一 次 对 refs/top-bases/t/feature3 引 用 指向 的 特性 分 支 的 基 
准 分 支 合 并 成 功 ， 但 对 Ufeature3 特 性 分 支 进行 的 合并 出 错 了 。 


执行 tg info 命 令 查 看 一 下 当前 分 支 t/feature3 的 状态 。 





$ tg info 
Topic Branch: t/feature3 (3/2 commits) 
Subject: [PATCH] t/feature3 
Base: 37dcb62 
* Base is newer than head! Please run ‘tg update . 
Depends: t/featurel1 
t/feature2 
Up-to-date. 





从 上 面 tg info 命 令 的 输出 可 以 看 出 当前 分 文 的 状态 是 Up-to-date， 但 
是 输出 中 包含 一 个 提示 : 分 支 的 基 (Base) 要 比 头 〈Head) 新 ， 请 执行 
tg update 命令 


这 时 如 果 执 行 tg summary 命 令 的 话 ， 可 以 看 到 tfeature3 处 于 


B (Break) 状态 。 





$ tg Summary 


t/featurel1 [PATCH] t/featurel1 
0 t/feature2 [PATCH] t/feature2 
> B t/feature3 [PATCH] t/feature3 





执行 git status 命 令 ， 可 以 看 出 因为 两 个 分 文 同时 修改 了 文件 hacks.txt 
而 导致 冲突 。 





$ git status 
# On branch t/feature3 
# Unmerged paths: 


# (use "git add/rm <file>..." as appropriate to mark resolution) 
# 

# both modified: hacks. txt 

# 

no changes added to commit (use "git add" and/or "git commit -a") 





可 以 编辑 hacks.txt 文 件 ， 或 者 调用 冲突 解决 工具 解决 冲突 ， 之 后 再 
提交 ， 这 才 真 正 完成 了 此 次 tg update。 





$ git mergetool 
$ git commit -m "resolved conflict with t/featurel1." 
$ tg info 
Topic Branch: t/feature3 (4/2 commits) 
Subject: [PATCH] t/feature3 
Base: 37dcb62 
Depends: t/featurel 
t/feature2 
Up-to-date. 





5.tg summary 命 令 


tg Summary 命 令 用 于 显示 Topgit 管 理 的 特性 分 文 的 列表 及 各 个 分 文 
的 状态 。 用 法 如 下 : 





tg [...] summary [-t | --sort | --deps | --graphviz] 





不 带 任何 参数 执行 tg summary 是 最 常用 的 Topgit 命 令 。 在 介绍 不 带 


参数 的 tg summary 命 令 之 前 ， 先 看 看 该 命令 的 其 他 用 法 。 


使 用 -t 参 数 显 示 特 性 分 文 列表 。 





$ tg summary -t 
t/feature1 
t/feature2 
t/feature3 





使 用 --deps 参 数 除了 显示 Topgit 特 性 分 文 外 ， 还 会 亚 示 特性 分 文 的 依 
赖 分 文 。 





$ tg summary --deps 
t/featurei1 master 
t/feature2 master 
t/feature3 t/featurel1 
t/feature3 t/feature2 





使 用 --sort 参 数 按照 分 文 依赖 的 顺序 显示 分 文 列 表 ， 除 了 显示 Topgit 
分 文 外 ， 还 会 显示 依赖 的 非 Topgit 分 文 。 





$ tg summary --sort 
t/feature3 
t/feature2 
t/feature1 

master 





使 用 --graphviz 会 输出 GraphViz 格 式 文 件 ， 可 以 用 于 显示 特性 分 支 之 
间 的 关系 。 





$ tg summary --graphviz | dot -T png -o topgit.png 





生成 的 特性 分 文 天 系 图 如 图 22-4 所 示 。 


TopGit Layout 
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图 22-4 Topgit 特 性 分 支 依赖 关系 图 











不 带 任 何 参 数 执行 tg summary 显 示 分 支 列 表 及 状态 。 这 是 最 常用 的 


Topgit 命 令 之 一 。 





$ tg summary 





t/feature1 [PATCH] t/featurel1 

0 t/feature2 [PATCH] t/feature2 

> t/feature3 [PATCH] t/feature3 
其 中 : 


. 标识 “>”: (t/feature3 分 支 之 前 的 大 于 号 ) 用 于 标记 当前 所 处 
的 特性 分 支 。 


. 标记 “0”: (t/feature2 分 支 前 的 数字 0) 含义 是 该 分 支 中 没有 提 
交 ， 这 是 一 个 建立 后 尚未 使 用 或 废弃 的 分 支 。 

. 标记 “DD”: 表明 该 分 支 处 于 过 时 (out-of-date) 状态 。 可 能 是 一 
个 或 多 个 依赖 的 分 支 包含 了 新 的 提交 ， 尚 未 合并 到 此 特性 分 支 。 可 以 用 
区 info 命 令 看 出 到 底 是 由 于 哪个 依赖 分 支 的 改动 导致 该 特性 分 支 处 于 过 
时 状态 。 

` 标记 “B”: 之 前 演示 中 出 现 过 ， 表 明 该 分 支 处 于 Break 状 态 ， 即 
可 能 由 于 冲突 未 解决 或 其 他 原因 导致 该 特性 分 支 的 基准 分 支 (base) 相 
对 该 分 支 的 头 (head) 不 匹配 。 例 如 refs/top-bases 下 的 特性 分 支 的 基准 
分 支 迁 移 了 ， 但 是 特性 分 支 未 完成 迁移 。 


` 标记 “! ”: 表明 该 特性 分 支 所 依赖 的 分 支 不 存在 。 


` 标记 “1 : 表明 该 特性 分 支 只 存在 于 本 地 ， 不 存在 于 远程 跟踪 


服务 器 。 


-标记 f : 表明 该 特性 分 支 既 存在 于 本 地 ， 又 存在 于 远程 跟踪 


服务 器 ， 并 且 两 者 匹配 。 
- 标记“L”: 表明 该 特性 分 支 ， 本 地 的 比 远程 跟踪 服务 器 的 新 。 


. 标记 “R ”: 表明 该 特性 分 支 ， 远 程 跟踪 服务 器 的 比 本 地 的 新 。 


. 如 果 没 有 出 现 “l/t/L/R”: 表明 该 版 本 库 尚 未 设置 远程 版 本 


-一般 带 有 标记 + 的 是 最 常见 的 ， 也 是 最 正常 的 。 








下 面 要 介绍 的 tg remote 命 令 为 测试 版 本 库 建 立 一 个 对 应 的 远程 版 本 
库 ， 然 后 就 能 在 tg summary 的 输出 中 看 到 “WL/R” 等 标识 符 了 。 


6.tg remote 命 令 





tg remote 命 令 用 于 为 远程 版 本 库 增 加 Topgit 的 相关 设置 ， 以 便 在 和 
该 远程 版 本 库 进 行 git fetch、git pull 等 操作 时 能 够 同步 Topgit 的 相关 分 
文 。 命 令 用 法 如 下 : 





tg [...] remote [--populate] [REMOTE] 








其 中 REMOTE 为 远程 版 本 库 的 名 称 ， 默 认为 origin。 执 行 tg remote 
命令 会 自动 在 版 本 的 配置 文件 中 增加 的 refs/top-bases 下 引用 同步 表达 
式 。 下 面 的 示例 中 的 最 后 一 行 就 是 执行 tg remote origin 后 增加 的 设置 。 





[remote "origin"] 
url = /path/to/repos/tgtest.git 
fetch = +refs/heads/*:refs/remotes/origin/* 
fetch = +refs/top-bases/*:refs/remotes/origin/top-bases/* 





如 果 使 用 --populate 参 数 ， 除 了 会 徊 上 面 那 样 设置 默认 的 Topgit 远 程 
版 本 库 外 ， 还 会 自动 执行 git fetch 命 令 ， 然 后 在 本 地 建立 Topgit 特 性 分 支 


和 对 应 的 基准 分 文 。 


当 执 行 tg 命令 时 ， 如 果 不 用 -r remote 全 局 参数 ， 则 默认 使 用 origin 远 
程 版 本 库 。 





下 面 为 前 面 测试 的 Topgit 版 本 库 设 置 一 个 远程 版 本 库 ， 具 体操 作 过 
程 如 下 。 


(1) 先 创建 一 个 裸 版 本 库 tgtest.git。 





$ git init --bare /path/to/repos/tgtest.git 
Initialized empty Git repository in /path/to/repos/tgtest.git/ 





(2) 然后 执行 git remote 命 令 ， 将 刚刚 创建 的 版 本 库 以 origin 为 名 注 
册 为 远程 版 本 库 。 








$ git remote add origin /path/to/repos/tgtest.git 





(3) 执行 git push， 将 当前 版 本 库 的 master 分 文 推送 到 了 刚刚 创建 的 
远程 版 本 库 。 





$ git push origin master 
Counting objects: 7, done. 
Delta compression using up to 2 threads. 
Compressing objects: 100% (3/3), done. 
Writing objects: 100% (7/7), 585 bytes, done. 
Total 7 (delta 0), reused 0 (delta 0) 
Unpacking objects: 100% (7/7), done. 
To /path/to/repos/tgtest.git 

* [new branch] master -> master 


| 





(4) 之 后 运行 tremote 命 令 为 远程 版 本 库 添 加 额外 的 配置 ， 以 便 
该 远程 版 本 库 能 够 跟踪 Topgit 分 文 。 





$ tg remote --populate origin 








(5) 执行 了 上 面 的 tg remote 命 令 后 ， 会 在 当前 版 本 库 的 .git/config 
文件 中 添加 设置 《以 加 号 开头 的 行 ) : 








[remote "origin"] 
url = /path/to/repos/tgtest.git 
fetch = +refs/heads/*:refs/remotes/origin/* 


十 fetch = +refs/top-bases/*:refs/remotes/origin/top-bases/* 
+[topgit] 
十 remote = origin 








(6) 这 时 再 执行 tg summary 会 看 到 分 文 前 面部 有 标记 “1”， 即 本 地 
提交 比 远程 版 本 库 的 新 。 





$ tg summary 


1 t/feature1i [PATCH] t/featurel1 
91 t/feature2 [PATCH] t/feature2 
> 工 t/feature3 [PATCH] t/feature3 





(7) 执行 tg push 命 令 将 特性 分 支 Vfeature2 及 其 基准 分 支 推送 到 远 
程 版 本 库 。 





$ tg push t/feature2 
Counting objects: 5, done. 
Delta compression using up to 2 threads. 
Compressing objects: 100% (3/3), done. 
Writing objects: 100% (4/4), 457 bytes, done. 
Total 4 (delta 0), reused 0 (delta 0) 
Unpacking objects: 100% (4/4), done. 
To /path/to/repos/tgtest.git 

* [new branch] t/feature2 -> t/feature2 


* [new branch] refs/top-bases/t/feature2 -> refs/top-bases/t/feature2 





(8) 再 来 看 看 tg summary 的 输出 ， 会 看 到 tfeature2 的 标识 变 
为 “r"， 即 远程 和 本 地 同步 。 





$ tg summary 


1 t/feature1 [PATCH] t/featurel1 
Or t/feature2 [PATCH] t/feature2 
>1 t/feature3 [PATCH] t/feature3 





(9) 运行 tg push--all dl ， 会 将 所 有 的 Topgit 分 支 推送 到 远程 版 本 
库 。 之 后 再 来 看 tg summary 的 输出 ， 会 看 到 所 有 分 支 都 带 上 了 “rm 的 标 


二。 





$ tg push --all 


$ tg summary 


r t/feature1i [PATCH] t/featurel1 
Or t/feature2 [PATCH] t/feature2 
>r t/feature3 [PATCH] t/feature3 





如 果 版 本 库 设 置 了 多 个 远程 版 本 库 ， 要 针对 每 一 个 远程 版 本 库 执行 
tg remote<REMOTE>， 但 只 能 有 一 个 远程 的 源 用 --populate 参 数 调 用 tg 
remote 将 其 设置 为 默认 的 远程 版 本 库 。 


7.tg push 命 令 


在 前 面 tg remote 的 介绍 中 ， 已 经 看 到 过 tg push 命 令 。tg push 命 令 用 


于 将 Topgit 特 性 分 文 及 对 应 的 基准 分 文 推送 到 远程 版 本 库 。 用 法 如 下 : 








tg [...] push [--dry-run] [--no-deps] [--tgish-only] [--alllbranch*] 


tg push 命 令 后 面 的 参数 指定 要 推送 给 远程 服务 器 的 分 支 列表 ， 如 果 
省 略 则 推送 当前 分 支 。 改 进 的 tg push 命 令 文 持 通 过 --all 参 数 将 所 有 
Topgit 特 性 分 支 推送 到 远程 版 本 库 。 








参数 --dry-run 用 于 测试 推送 的 执行 效果 ， 而 不 是 真正 执行 。 参 数 - 
no-deps 的 含义 是 不 推送 依赖 的 分 支 ， 默认 推送 。 参 数 --tgish-only 的 含义 
征 只 推送 Topgit 竺 性 分 文 ， 默 认 推 送 指定 的 所 有 分 文 。 


8.tg depend 命 令 





tg depend 命 令 目前 仅 实 现 了 为 当前 的 Topgit 特 性 分 支 增 加 新 的 依 
赖 。 用 法 如 下 : 


tg [...] depend add NAME 


将 NAME 加 入 到 文件 .topdeps 中 ， 并 将 NAME 分 支 问 该 特性 分 支 及 
特性 分 支 的 基准 分 支 进行 合并 操作 。 虽 然 Topgit 可 以 检查 到 分 支 的 循环 
依赖 ， 但 还 是 要 注意 合理 地 设置 分 支 的 依赖 ， 合 并 重复 的 依赖 。 





9.tg base 命 令 
tg base 命 令 用 于 显示 特性 分 支 的 基准 分 支 的 提交 ID 〈 精 简 格式 ) 。 


10.tg delete 命 令 





tg delete 命 令 用 于 删除 Topgit 特 性 分 文 及 其 对 应 的 基准 分 文 。 用 法 如 
下 : 





tg [...] delete [-f] NAME 





默认 只 删除 没有 改动 的 分 文 ， 即 标记 为 “0” 的 分 文 ， 除 非 使 用 -f 参 
数 。 


目前 此 命令 尚 不 能 自动 清除 其 分 文中 对 删除 分 文 的 依赖 ， 还 需要 手 
工 调 整 .topdeps 文 件 ， 删 除 对 不 存在 的 分 文 的 依赖 。 





11.tg patch 命 令 





tg patch 命 令 通过 比较 特性 分 文 及 其 基准 分 文 的 兰 异 ， 显 示 该 特性 分 


支 的 补丁 。 用 法 如 下 : 





tg [...] patch [-i | -w] [NAME] 





其 中 -i 参 数 显 示 暂 存 区 和 基准 分 文 的 兰 异 。-w 参 数 显 示 工 作 区 和 基 
准 分 支 的 差异 。 











tg patch 命 令 存在 的 一 个 问题 是 只 能 正确 显示 工作 区 中 的 根 执行 。 这 
个 缺陷 已 经 在 我 改进 的 Topgit 中 被 改正 中 。 


12.tg export 命 令 


tg export 命 令 用 于 导出 特性 分 文 及 其 依赖 ， 便 于 同上 游 贡 献 。 可 以 
导出 Quilt 格 式 的 补丁 列表 ， 或 者 顺序 提交 到 另外 的 分 文中 。 用 法 如 下 : 








tg [...] export ([--collapse] NEWBRANCH | [--all | -b BRANCH1, BRANCH2...] --quilt D 








这 个 命令 有 三 种 导出 方法 。 


“ 将 所 有 的 Topgit 特 性 分 支 压缩 为 一 个 ， 提 交 到 新 的 分 支 。 





tg [...] export --collapse NEWBRAQNCH 





* 将 所 有 的 Topgit 特 性 分 支 按照 线性 顺序 提交 到 一 个 新 的 分 支 中 。 





tg [...] export --linearize NEWBRANCH 





` 将 指定 的 Topgit 分 支 ( 一 个 或 多 个 ) 及 其 依赖 分 支 转换 为 Quilt 格 
式 的 补丁 ， 保 存 到 指定 目录 中 。 





tg [...] export -b BRANCH1, BRANCH2,., --quilt DIRECTORY 





在 导出 为 Quilt 格 式 补丁 的 时 候 ， 如 果 想 将 所 有 的 分 文 叶 出 ， 必 须 
用 -pb 参数 将 分 文 全 部 罗列 《或 者 分 文 的 依赖 关系 将 所 有 分 文 喜 括 ) ， 这 
对 于 需要 导出 所 有 分 文 的 操作 非常 不 方便 。 我 改进 的 Topgit 通 过 --all 参 
数 实现 了 所 有 分 支 的 导出 。 





13.tg import 命 令 


tg import 命 令 将 分 文 的 提交 转换 为 Topgit 特 性 分 文 ， 指 定 范 围 的 
个 提交 都 转换 为 一 个 特性 分 文 ， 各 个 特性 分 文 之 间 线 性 依赖 。 用 法 如 
下 : 





tg [...] import [-d BASE_BRANCH] {[-p PREFIX] RANGE...|-s NAME COMMIT} 





如 果 不 使 用 -d 参 数 ， 特 性 分 文 则 以 当前 分 文 为 依赖 。 特 性 分 文 名 称 
目 动 生 成 ， 使 用 约定 俗 成 的 t/ 作 为 前 级 ， 也 可 以 通过 -p 参 数 指定 其 他 前 
级 。 可 以 通过 -s 参 数 设 定 特 性 分 文 的 名 称 。 


14.tg log 命 令 


tg log 命 令 显 示 特 性 分 文 的 提交 历史 ， 并 忽略 合并 引入 的 提交 。 





tg [...] log [NAME] [-- GIT LOG OPTIONS...] 





tg log 命 令 实际 是 对 git log 命 令 的 封装 。 这 个 命令 通过 --no-merges 和 - 
-first-parent 参 数 调用 git log， 虽 然 屏蔽 了 大 量 因 和 依赖 分 文 合 并 而 引入 
的 依赖 分 支 的 提交 日 志 ， 但 是 同时 也 屏蔽 了 合并 到 该 特性 分 支 的 其 他 贡 
献 者 的 提交 。 








15.tg mail 命 令 





tg mail 命 令 将 当前 分 文 或 指定 特性 分 文 的 补丁 以 邮件 的 形式 外 发 。 


用 法 如 下 : 





tg [...] mail [-s SEND_EMAIL ARGS] [-r REFERENCE_ MSGID] [NAME] 





tg mail 调 用 git send-email 发 送 邮件 ， 参 数 -s 用 于 向 该 命令 传递 参数 
《需要 用 双 引 号 括 起 来 ) 。 邮 件 中 的 目的 地 址 从 补丁 文件 头 中 的 To、 
Cc 和 Bcc 等 字段 获取 。 参 数 -了 引 用 回复 邮件 的 ID 以 便 正 确 地 生成 in-reply- 
to 邮件 头 。 


注意 : 此 命令 可 能 会 发 送 多 封 邮 件 ， 可 以 通过 如 下 设置 在 调用 git 
send-email 命 令 发 送 邮件 时 进行 确认 。 





$ git config sendemail.confirm always 





16.tg files 命 令 
tg files 命 令 用 于 显示 当前 或 指定 的 特性 分 文 改 动 了 哪些 文件 。 
17.tg prev 命 令 
tg prev 命 令 用 于 显示 当前 或 指定 的 特性 分 文 所 依赖 的 分 文 名。 


18.tg next 命 令 


tg next 命 令 用 于 显示 当前 或 指定 的 特性 分 文 被 其 他 哪些 特性 分 文 所 
依赖 。 


19.tg graph 命 令 





tg graph 命 令 并 非 官方 提供 的 命令 ， 而 是 源 自 一 个 补丁 品 ， 实 现 文 
本 方式 的 Topgit 分 文 图 。 当 然 这 个 文本 分 文 图 没有 tg summary--graphviz 
生成 的 那么 漂亮 





[1 改进 后 的 Topgit 才 提供 同步 全 部 特性 分 支 的 功能 。 
[2] 最 新 的 Topgit 重 构 了 tg-push 的 代码 ， 改 正 了 这 个 缺陷 ， 所 以 会 看 到 最 
新 改进 版 的 Topgit 该 特性 分 支 为 空 。 


[3] http:/ /kerneltrap.org/ mailarchive/ git/2009/5/20/2922 


22.5 用 Topgit 方 式 改 造 Topgit 


在 Topgit 的 使 用 中 陆续 发 现 了 一 些 不 合用 的 地 方 ， 于 是 便 以 Topgit 
特性 分 文 的 方式 来 对 Topgit 进 行 改 造 。 在 群英 汇 的 博客 上 介绍 了 如 下 几 


不 区 二 








. TopGit 改 进 (1) : tgpush 全 部 分 支 中 
.TopGit 改 进 (2) : te 导出 全 部 分 支 站 
.TopGit 改 进 (3) : 更 灵活 的 tpatch 
.TopGit 改 进 (4) : t 命 令 补 齐 门 

. TopGit 改 进 (5) : tg summary 执 行 的 更 快 中 


下 面 就 以 Topgit 改 造 过 程 为 例 ， 来 介绍 如 何 参 与 一 个 Topgit 管 理 下 
的 项 目的 开发 。 改 造 后 的 Topgit 版 本 库 地 址 为 : git://github.com/ossxp- 


com/topgit.git。 


首先 元 隆 该 版 本 库 : 





$ git clone git://github.com/ossxp-com/topgit.git 
$ cd topgit 





查看 远程 分 文 : 





$ git branch -r 

origin/HEAD -> origin/master 
origin/master 
origin/t/debian_locations 
origin/t/export_quilt_all 
origin/t/fast_tg_summary 
origin/t/graphviz_layout 
origin/t/tg_completion_bugfix 
origin/t/tg_graph_ascii output 
origin/t/tg_patch_cdup 
origin/t/tg_push_all 
origin/tgmaster 





看 到 远程 分 支 中 出 现 了 熟悉 的 以 t/ 为 前 级 的 Topgit 分 支 ， 说 明 这 个 
版 本 库 是 一 个 由 Topgit 进 行 管理 的 版 本 库 。 为 了 能 够 获取 Topgit 各 个 特 
性 分 支 的 基准 分 支 ， 需 要 用 tg remote 命 令 对 默认 的 origin 远 程 版 本 库 注册 
一 下 





$ tg remote --populate origin 

tg: Remote origin can now follow TopGit topic branches. 

tg: Populating local topic branches from remote 'origin'... 
From git://github.com/ossxp-com/topgit 


* [new branch] refs/top-bases/t/debian_locations -> 
origin/top-bases/t/debian_locations 

* [new branch] refs/top-bases/t/export_quilt_all -> 
origin/top-bases/t/export_quilt_ all 

* [new branch] refs/top-bases/t/fast_tg_summary -> 
origin/top-bases/t/fast_tg_summary 

* [new branch] refs/top-bases/t/graphviz_layout -> 
origin/top-bases/t/graphviz_layout 

* [new branch] refs/top-bases/t/tg_completion _ bugfix -> 
origin/top-bases/t/tg_completion_bugfix 

* [new branch] refs/top-bases/t/tg_graph_ascii output -> 
origin/top-bases/t/tg_graph_ascii output 

* [new branch] refs/top-bases/t/tg_patch_cdup -> 
origin/top-bases/t/tg_patch_cdup 

* [new branch] refs/top-bases/t/tg_push _all -> 


origin/top-bases/t/tg_push_all 

tg: Adding branch t/debian locations... 

tg: Adding branch t/export_quilt all... 

tg: Adding branch t/fast_tg_ summary... 

tg: Adding branch t/graphviz_layout... 

tg: Adding branch t/tg_completion bugfix... 
tg: Adding branch t/tg_graph_ascii output... 
tg: Adding branch t/tg_patch_cdup... 


tg: Adding branch t/tg_push all... 
tg: The remote 'origin' is now the default source of topic branches. 





执行 tg summary 人 查看 一 下 本 地 Topgit 特 性 的 分 支 状态 。 





$ tg summary 


r ! t/debian locations [PATCH] make file locations Debian-c 
rr ! t/export_quilt_all [PATCH] t/export_quilt all 

rr ! t/fast_tg_summary [PATCH] t/fast_tg_summary 

rr ! t/graphviz_layout [PATCH] t/graphviz_layout 

rr ! t/tg completion bugfix [PATCH] t/tg_completion_ bugfix 

r t/tg_graph_ascii output [PATCH] t/tg_graph_ascii output 

r ! t/tg_ patch _cdup [PATCH] t/tg_patch_ cdup 

rr ! t/tg_push_all [PATCH] t/tg_push _all 








怎么 ? 出 现 了 感叹 号 ? 记得 前 面 在 介绍 tg summary 命 令 的 章节 中 提 
到 过 ， 感 叹 写 的 出 现 说 明 该 特性 分 文 所 依赖 的 分 支 丢 失 了。 用 tg info 查 
看 一 下 其 中 的 茶 个 特性 分 文 。 





$ tg info t/export_quilt_all 

Topic Branch: t/export_quilt _ all (6/4 commits) 
Subject: [PATCH] t/export_quilt all 

Base: 8bof1f9 

Remote Mate: origin/t/export_quilt_ all 
Depends: tgmaster 

MISSING: tgmaster 

Up-to-date. 





原来 该 特性 分 文 依赖 tgmaster 分 文 ， 而 不 是 master 分 文 。 远 程 存在 
tgmaster 分 文 而 本 地 尚 不 存在 。 于 是 在 本 地 建 并 tgmaster 跟 躁 分 文 。 





$ git checkout tgmaster 
[6] 


Branch tgmaster set up to track remote branch tgmaster from origin. 


Switched to a new branch 'tgmaster' 





这 回 tg summary 的 输出 正常 了 。 





$ tg Summary 


r 


i 


t/debian locations 
t/export_quilt_all 
t/fast_tg_summary 
t/graphviz_layout 
t/tg_completion bugfix 


[PATCH] 


[PATCH] 


t/tg_graph_ascii output [PATCH] 


t/tg_patch_cdup 
t/tg_push_all 


[PATCH] 
[PATCH] 


[PATCH] make file locations Debian-compatib] 
t/export_quilt_all 

[PATCH] t/fast_tg_summary 

[PATCH] t/graphviz_layout 

t/tg_completion bugfix 

t/tg_graph_ascii output 

t/tg_patch_cdup 

t/tg_push_all 





通过 下 面 的 命令 创建 图 形 化 的 分 支 图 。 





$ tg summary --graphviz | dot -T png -o topgit.png 





生成 的 特性 分 支 天 系 图 如 图 22-5 所 示 。 


TopGit Layout 


t/debian _ locations 


t/export quilt all 


t/fast tg summary t/tg graph ascil Output 
tgmaster ] t/graphviz layout 


t/tg completion bugfix 
t/tg patch cdup 


t/tg_ push al 


图 22-5 Topgit 改 进项 目的 特性 分 支 依赖 关系 图 
~ 中 : 


特性 分 支 t/export_quilt_all， 为 tg expott--quilt 命 令 增 加 --al 选 项 ， 
以 便 导 出 所 有 的 特性 分 支 。 


. 特性 分 支 t/fast_te_summary， 主 要 是 改进 te 命令 补 齐 时 分 支 的 显 


示 速 度 ， 当 特性 分 支 接近 上 百 个 时 差异 非常 明显 。 
. 特性 分 支 t/graphviz_layout， 改 进 了 分 支 的 图 形 输 出 格式 。 
` 特性 分 支 t/tg_completion_bugfix， 解 决 了 命令 补 齐 的 一 个 Bug。 


* 特性 分 支 t/te_graph_ascii_output， 源 自 Bert Wesarg 的 贡献 ， 非 常 
巧妙 地 实现 了 文本 化 的 分 支 图 显示 ， 展 示 了 gvpr 命 令 的 强大 功能 。 


“ 特性 分 支 t/tg_patch_cdup， 解 决 了 在 项 目的 子 目 录 下 无 法 执行 tg 


patch 的 问题 。 


* 特性 分 支 t/tg_push_all， 通 过 为 tg push 增 加 --all 选 项 ， 解 决 了 当 tg 
从 0.7 版 升级 到 0.8 版 后 ， 无 法 批量 向 上 游 推送 特性 分 支 的 问题 。 





下 面 展 示 一 下 如 何 跟踪 上 游 的 最 新 改动 ， 并 迁移 到 新 的 上 游 版 本 。 
分 文 {gmaster 用 于 跟踪 上 游 的 Topgit 分 文 ， 以 V 开 头 的 分 文 是 对 Topgit 改 
进 的 特性 分 文 ， 而 master 分 文 实际 上 是 导出 Topgit 补 丁 文件 并 负责 编译 
特定 Linux 平 台 发 行 包 的 分 文 。 有 具体 操作 过 程 如 下 : 


(1) 把 官方 的 Topgit 版 本 库 以 upstream 的 名 称 加 入 作为 新 的 远程 版 
本 库 。 





$ git remote add upstream git://repo.or.cz/topgit.git 





(2) 然后 将 upstream 远 程 版 本 的 master 分 支 合 并 到 本 地 的 tgmaster 
Ns 





$ git pull upstream master:tgmaster 
From git://repo.or.cz/topgit 
29ab4cf. .8bof1f9 master -> tgmaster 





(3) 此 时 再 执行 tg summary 会 发 现 所 有 的 Topgit 分 支 都 多 了 一 个 标 
记 D， 表 明 因 为 依赖 分 支 的 更 新 而 导致 Topgit 特 性 分 支 过 时 了 。 





$ tg summary 


roD t/debian_ locations [PATCH] make file locations Debian-c 
roD t/export_quilt_all [PATCH] t/export_quilt all 

roD t/fast_tg_summary [PATCH] t/fast_tg_summary 

roD t/graphviz_layout [PATCH] t/graphviz_layout 

roD t/tg_completion _ bugfix [PATCH] t/tg_completion_ bugfix 

roD t/tg_graph_ascii output [PATCH] t/tg_graph_ascii output 

roD t/tg_patch_cdup [PATCH] t/tg_patch _cdup 

roD t/tg_push_all [PATCH] t/tg_push _all 





(4) 依次 对 各 个 分 支 执 行 tg update， 完 成 对 更 新 的 依赖 分 支 的 合 
J 





$ tg update t/export_quilt all 





(5) 对 各 个 分 文 完 成 更 新 后 ， 会 发 现 t{g summary 的 输出 中 ， 标 识 
过 时 的 D 标 记 变 为 L， 即 本 地 比 远程 服务 器 分 文 要 新 。 





$ tg Summary 


rL t/debian_ locations [PATCH] make file locations Debian-c 
rL t/export_quilt_all [PATCH] t/export_quilt all 

rL t/fast_tg_summary [PATCH] t/fast_tg_summary 

rL t/graphviz_layout [PATCH] t/graphviz_layout 


rL t/tg_completion_ bugfix [PATCH] t/tg_completion_ bugfix 


rL t/tg_graph_ascii output [PATCH] t/tg_graph_ascii output 
rL t/tg_patch_cdup [PATCH] t/tg_patch_cdup 
rL t/tg_push_all [PATCH] t/tg_push _all 





(6) 执行 tg push--all 就 可 以 实现 将 所 有 的 Topgit 特 性 分 支 推送 到 远 
程 服务 器 上 ， 当 然 需要 有 提交 权限 才 可 以 。 








[1] http://blog.ossxp.com/2010/01/247/ 
[2] http://blog.ossxp.com/2010/01/255/ 
[3] http://blog.ossxp.com/2010/01/257/ 
[4] http://blog.ossxp.com/2010/01/259/ 
[5] http://blog.ossxp.com/2010/01/261/ 
[6]| ”如 果 Git 版 本 号 小 于 1.6.6， 则 需要 执行 git checkout -b tgmaster 


origin/tgmastet 命 令 以 创建 tgmaster 分 支 。 


22.6 ”Topgit 使 用 中 的 注意 事项 


1. 经 常 运行 tg remote--populate 获 取 他 人 创建 的 特性 分 支 





运行 命令 git fetch 或 命令 git pull 和 远程 版 本 库 同 步 ， 只 能 将 他 人 创建 
的 Topgit 特 性 分 支 在 本 地 以 远程 分 支 (refs/remotes/origin/t/<branch- 
name>) 的 方式 保存 ， 而 不 能 自动 在 本 地 建立 分 文 。 





如 果 确 认 版 本 库 是 使 用 Topgit 维 护 的 话 ， 应 该 在 和 远程 版 本 库 同步 
的 时 候 执 行 tg remote--populate origin。 这 条 命令 会 做 两 件 事 情 : 


. 自动 调用 git fetch origin 获 取 远 程 origin 版 本 库 的 新 的 提交 和 引用 。 


` 检查 refs/remotes/origin/top-bases/ 下 的 所 有 引用 ， 如 果 是 新 的 ， 
在 本 地 (refs/top-bases/) 尚 不 存在 ， 说 明 有 其 他 人 创建 了 新 的 特性 分 
支 。Topgit 会 据 此 自动 在 本 地 创建 新 的 特性 分 支 。 


2. 适 时 地 调整 特性 分 支 的 依赖 关系 


例如 之 前 用 于 Topgit 演 示 的 版 本 库 ， 各 个 特性 分 支 的 依赖 文件 内 容 
如 下 。 


` 分 支 t/featurel 的 .topdeps 文 件 





master 


` 分 支 t/feature2 的 .topdeps 文 件 





master 





` 分 支 t/feature3 的 .topdeps 文 件 





t/feature1 
t/feature2 





如 果 分 文 t/feature3 的 .topdeps 文 件 是 这 样 的 ， 可 能 就 会 存在 问题 。 





master 
t/feature1 
t/feature2 





问题 在 于 t/feature3 依 赖 的 其 他 分 支 已 经 依赖 了 master 分 文 ， 虽然 不 
会 造成 致命 的 影响 ， 但 是 在 特定 情况 下 这 种 重复 会 造成 不 便 。 例 如 在 
master 分 文 更 新 后 ， 可 能 由 于 代码 重 构 的 比较 厉害 ， 在 特性 分 文 迁移 时 
会 造成 冲突 ， 如 在 t/featurel 分 文中 执行 tg update 会 遇 到 冲突 ， 当 辛 盏 完 
成 冲突 解决 并 提交 后 ， 在 tfeature3 中 执行 tg update 会 因为 先 依 赖 的 是 
master 分 支 ， 所 以 先 在 master 分 支 上 对 t/feature3 分 支 进行 合并 ， 这 样 就 肯 
定 会 遇 到 和 tfeature1 相 同 的 冲突 ， 还 要 再 重复 解决 一 次 。 





如 果 在 .topdeps 文 件 中 删除 了 对 master 分 支 的 重复 的 依赖 ， 就 不 会 出 
现 上 面 的 重复 解决 冲突 的 问题 了 。 


同样 的 道理 ， 如 果 tfeature3 的 .topdeps 文 件 写成 这 样 ， 效 果 也 将 不 
同 : 


t/feature2 
t/feature1 


依赖 的 顺序 不 同 会 造成 合并 的 顺序 也 不 同 ， 同 样 也 会 产生 重复 的 冲 
突 解 决 。 因 此 当 发 现 重复 的 冲突 时 ， 可 以 取消 合并 操作 ， 修 改 特性 分 文 
的 .topdeps 文 件 ， 调 整 文件 内 容 〈 删 除 重 复 分 文 ， 调 整 分 文 顺序 ) 并 提 
交 ， 然 后 再 执行 tg update 继 续 合 并 操作 。 


3.Topgit 特 性 分 支 的 里 程 碑 和 分 支管 理 


Topgit 本 身 束 是 管理 特性 分 文 的 软件 。Topgit 采 个 时 刻 的 开发 状态 
征 Topgit 管 理 下 的 所 有 分 文 〈 包 括 基 准 分 文 ) 整体 的 状态 。 思 考 一 下 : 
能 够 用 里 程 碑 来 标记 Topgit 管 理 的 版 本 库 的 开发 状态 吗 ? 








使 用 里 程 碑 来 管理 是 不 可 能 的 ， 因 为 Git 里 程 碑 只 能 针对 一 个 分 文 
做 标记 而 不 能 标记 所 有 的 分 文 。 使 用 死 隆 是 唯一 的 方法 。 死 隆 不 但 用 于 
标记 Topgit 版 本 库 的 开发 状态 ， 也 可 以 用 于 Topgit 版 本 库 的 分 文 管理 。 
例如 一 旦 上 游 出 现 新 版 本 ， 就 从 当前 版 本 库 建 立 一 个 元 隆 ， 原 来 的 版 本 
库 用 于 维护 原 有 上 游 版 本 的 定制 开 及 ， 新 的 克隆 版 本 库 针 对 新 的 上 游 版 
本 进行 迁移 ， 用 于 新 的 上 游 版 本 的 特性 开发 。 





也 许 还 可 以 通过 其 他 方法 实现 ， 例 如 将 Topgit 所 有 相关 的 分 文 都 复 





制 到 一 个 特定 的 引用 目录 中 或 记录 在 文件 中 ， 以 实现 特性 分 支 的 状态 记 
录 。 


第 23 半 了 于 模 组 协同 模型 





项 目的 版 本 库 在 茶 些 情况 下 需要 引用 其 他 版 本 库 中 的 文件 ， 例 如 公 
司 积 累 了 一 套 第 用 的 函数 库 ， 被 多 个 项 目 调用 ， 显 然 这 个 函数 库 的 代码 
不 能 直接 放 到 东 个 项 目的 代码 中 ， 而 是 要 独立 为 一 个 代码 库 ， 那 么 其 他 
项 目 要 调用 公共 的 函数 库 该 如 何 处 理 呢 ? 分 别 把 公共 函数 库 的 文件 找 贝 
到 各 自 的 项 目 中 会 造成 元 余 ， 于 人 茎 了 公共 函数 库 的 维护 历史 ， 这 显然 不 
是 好 的 方法 。 本 章 要 讨论 的 子 模 组 协同 模型 ， 就 是 解决 这 个 问题 的 一 个 
方案 。 


熟悉 Subversion 的 用 户 马 上 会 想起 svn:externals 属 性 可 以 实现 对 外 部 
代码 库 的 引用 。Git 的 子 模 组 (submodule〉 是 类 似 的 一 种 实现 。 不 过 因 
为 Git 的 特殊 性 ， 二 者 的 区 别 还 是 蛮 大 的 ， 参 见 表 23-1。 


表 23-1 ”SVN 和 Git 相 似 功能 对 照 表 














svn:externals git submodule 
如 何 记录 外 部 版 本 库 的 地 址 目录 的 svn :externals 属性 项 目 根 目录 下 的 .gitmodules 文件 
是 否 
攻 a 在 使 用 svn checkout 检 出 时 ， 若 使 | 默认 不 克隆 外 部 版 本 库 。 若 要 克隆 则 
默认 是 否 自动 检 出 外 部 版 本 库 用 参数 --ignore-externals 可 以 | 用 git submodule init 及 git 
忽略 对 外 部 版 本 库 的 引用 不 检 出 submodule update 命令 
~ 、 2 是 否 
是 否 能 部 分 引用 外 部 版 本 库 内 容 。 | 因为 SVN 支持 部 分 检 出 必须 克隆 整个 外 部 版 本 认 
sd 否 
目 不 百 名 分 3 区 日 








23.1 创建 子 模 组 


在 演示 子 模 组 的 创建 和 使 用 之 前 ， 先 做 些 准备 工作 。 先 尝试 建立 两 
个 公共 函数 库 〈libA.git 和 1libB.git) ， 以 及 一 个 引用 函数 库 的 主 版 本 库 
(super.git) 。 





$ git --git-dir=/path/to/repos/libA.git init --bare 
$ git --git-dir=/path/to/repos/libB.git init --bare 
$ git --git-dir=/path/to/repos/super.git init --bare 











器 两 个 公共 的 函数 库 中 填充 些 数据 。 这 就 需要 在 工作 区 克隆 两 个 函 
数 库 ， 提 交 数 据 并 推送 。 


克隆 libA.git 版 本 库 ， 添 加 一 些 数据 ， 然 后 提交 并 推送 。 说 明 : 示例 
中 显示 为 hack... 的 地 方 做 了 一 些 改动 (如 创建 新 文件 等 ) ， 并 将 改动 添 
加 到 暂 存 区 








$ git clone /path/to/repos/libA.git /path/to/my/workspace/l1ibA 
$ cd /path/to/my/workspace/1ibA 

hack ... 

$ git commit -m "add data for libA" 

$ git push origin master 





克隆 libB.git 版 本 库 ， 洪 加 一 些 数据 ， 然 后 提交 并 推送 。 





$ git clone /path/to/repos/libB.git /path/to/my/workspace/l1ibB 
$ cd /path/to/my/workspace/libB 

hack ... 

$ git commit -m "add data for libB" 

$ git push origin master 





版 本 库 super 是 准备 在 其 中 创建 子 模 组 的 。super 版 本 库 刚 刚 初 始 化 
还 未 包含 提交 ，master 分 支 尚 未 有 正确 的 引用 。 需 要 在 super 版 本 库 中 至 
少 创建 一 个 提交 。 下 面 就 克隆 super 版 本 库 ， 在 其 中 完成 一 个 提交 〈 空 提 
交 即 可 ) ， 并 推送 。 





$ git clone /path/to/repos/super.git /path/to/my/workspace/super 
$ cd /path/to/my/workspace/super 

$ git commit --allow-empty -m "initialized." 

$ git push origin master 





现在 就 可 以 在 super 版 本 库 中 使 用 git submodule add 命 令 添加 子 模 组 
i 





$ git submodule add /path/to/repos/libA.git lib/lib a 
$ git submodule add /path/to/repos/libB.git lib/lib_b 








至 此 看 一 下 super 版 本 库 工 作 区 的 目录 结构 。 在 根 目 录 下 多 了 一 
个 .gitmodules 文 件 ， 并 且 两 个 函数 库 分 别 被 克隆 到 ib/lib_a 目 录 和 
lib/lib b 目 录 下 。 








$ ls -aF 
人/ ../ .git/ .gitmodules 1ib/ 





看 看 .gitmodules 的 内 容 : 





$ cat .gitmodules 
[submodule "lib/lib a"] 

path = lib/lib_a 

url = /path/to/repos/l1ibA.git 
[submodule "1ib/1ib_b"] 


path = lib/lib_b 
url = /path/to/repos/l1ibB.git 





此 时 super 的 工作 区 尚未 提交 。 





$ git status 

# On branch master 

# Changes to be committed: 

(use "git reset HEAD <file>..." to unstage) 


new file: .gitmodules 
new file: lib/lib_ a 
new file: lib/lib_b 


亲 亲 亲 亲 亲 和 宁 








完成 提交 之 后 ， 子 模 组 才 算 正式 在 super 版 本 库 中 创立 。 运 行 git 
push 把 建立 了 新 模 组 的 本 地 版 本 库 推送 到 远程 版 本 库 。 





$ git commit -m "add modules in lib/lib a and lib/lib_b." 
$ git push 





在 提交 过 程 中 ， 发 现 作 为 子 模 组 方式 添加 的 版 本 库 实际 上 并 没有 添 
加 版 本 库 的 内 容 。 实 际 上 只 是 以 gitlink 的 方式 添加 了 一 个 链接 。 至 于 子 
模 组 的 实际 地 址 ， 是 由 文件 .gitmodules 指 定 的 。 


可 以 通过 查看 补丁 的 方式 看 到 liby/lib a 和 1libylib _b 子 模 组 的 存在 方式 
(Bgitlink) 。 





$ git show HEAD 
commit 19bb54239dd7c11151e0odcb8b9389e146f055ba9 
Author: Jiang Xin <jiangxin@ossxp.com> 
Date: Fri Oct 29 10:16:59 2010 +0800 
add modules in lib/lib a and lib/lib_b. 

diff --git a/.gitmodules b/.gitmodules 
new file mode 100644 
index 0000000. .60c7d1f 

- /dev/null 


+++ b/.gitmodules 


@@ -0, 0 +1，6 @@ 
+[submodule "lib/lib_a"] 


+ path = lib/lib_a 
十 url = /path/to/repos/l1ibA.git 
+[submodule "lib/1lib_b"] 
+ path = lib/lib_b 
十 url = /path/to/repos/l1ibB.git 


diff --git a/lib/lib a b/lib/lib a 

new file mode 160000 

index 0000000, .126b181 

--- /dev/null 

+++ b/lib/lib_a 

@@ -0, 0 +1 @@ 

+Subproject commit 126b18153583d9bee4562f9af6b9706d2e104016 
diff --git a/lib/lib _b b/lib/lib_b 

new file mode 160000 

index 0000000, .3b52a71 

--- /dev/null 

+++ b/lib/lib_b 

@@ -0, 9 +1 @@ 

+Subproject commit 3b52a710068edc070e3a386a6efcbdf28bf1ibed5 


OO | 


23.2 ”克隆 市 子 模 组 的 版 本 库 





之 前 的 表 23-1 在 对 比 Subversion 的 svn:externals 属 性 和 Git 子 模 组 实现 
差异 时 ， 提 到 过 克隆 带子 模 组 的 Git 库 ， 并 不 能 自动 将 子 模 组 的 版 本 库 
克隆 出 来 。 对 于 只 关心 项 目 本 里 的 数据 ， 而 不 关心 项 目 引 用 的 外 部 项 目 
数据 的 用 户 ， 这 个 功能 非常 好 ， 数 据 没有 元 余 而 且 克 隆 的 速度 也 更 快 。 








下 面 在 男 外 的 位 置 元 隆 super 版 本 库 ， 会 发 现 lib/lib_a 和 lib/lib_b 并 未 
克隆 。 





$ git clone /path/to/repos/super.git /path/to/my/workspace/super-clone 
$ cd /path/to/my/workspace/super-clone 

$ ls -aF 

./ ../ .git/ .gitmodules 1ib/ 

$ find lib 

1ib 

lib/lib a 

lib/lib_b 





这 时 如 果 运 行 git submodule status 可 以 查看 到 子 模 组 的 状态 。 





$ git submodule status 
-126b18153583d9bee4562f9af6b9706d2e104016 lib/lib a 
-3b52a710068edc070e3a386a6efcbdf28bf1ibed5 1ib/1lib_b 








可 以 看 到 ， 每 个 子 模 组 的 目录 前 面 都 是 40 位 的 提交 ID， 最 前 面 的 是 
一 个 减 号 。 减 号 的 含义 是 该 子 模 组 尚未 检 出 。 


如 果 需 要 克隆 出 子 模 组 形式 引用 的 外 部 库 ， 首 先 需 要 执行 git 


submodule init 。 





$ git submodule init 
Submodule 'l1ib/lib a' (/path/to/repos/libA.git) registered for path 'lib/lib a' 
Submodule 'l1ib/lib _b' (/path/to/repos/libB.git) registered for path 'lib/lib_b' 





执行 git submodule init 实 际 上 修改 了 .git/config 文 件 ， 对 子 模 组 进行 
了 注册 。 文 件 .giVconfig 的 修改 示例 如 下 《以 加 号 开始 的 行 代表 新 增 的 


行 ) 。 





[core] 

repositoryformatversion = 0 

filemode = true 

bare = false 

logallrefupdates = true 
[remote "origin"] 

fetch = +refs/heads/*:refs/remotes/origin/* 

url = /path/to/repos/super.git 
[branch "master"] 

remote = origin 

merge = refs/heads/master 

+[submodule "lib/lib _a"] 


十 url = /path/to/repos/l1ibA.git 
+[submodule "lib/lib_b"] 
十 url = /path/to/repos/l1ibB.git 





然后 执行 git submodule update 完 成 子 模 组 版 本 库 的 克隆 。 





$ git submodule update 

Initialized empty Git repository in 
/path/to/my/workspace/super-clone/lib/lib _ a/ .git/ 
Submodule path 'lib/lib a': checked out 
"126b18153583d9bee4562f9af6b9706d2e104016 
Initialized empty Git repository in 
/path/to/my/workspace/super-clone/lib/lib_b/.git/ 
Submodule path 'lib/lib _b': checked out 
"3b52a710068edc070e3a386a6efcbdf28bf1bed5 


二 一 


23.3 ”在 子 模 组 中 修改 和 子 模 组 的 更 新 


执行 git submodule update 更 新 出 来 的 子 模 组 ， 都 以 某 个 具体 的 提交 
版 本 进行 检 出 。 进 入 某 个 子 模 组 目录 ， 会 发 现 其 处 于 非 跟踪 状态 〈 分 离 
头 指 针 状 态 ) 。 








$ cd /path/to/my/workspace/super-clone/lib/lib a 
$ git branch 
* (no branch) 





master 
显然 这 种 情况 下 ， 如 果 修 改 lib/lib_a 下 的 文件 ， 提 交 就 会 丢失 。 下 


面 介绍 一 下 如 何在 检 出 的 子 模 组 中 修改 ， 以 及 如 何 更 新 子 模 组 。 


在 子 模 组 中 切换 到 master 分 文 〈 或 其 他 想 要 修改 的 分 文 ) 后 再 进行 


(1) 切换 到 master 分 文 ， 然 后 在 工作 区 做 一 些 改动 。 





$ cd /path/to/my/workspace/super-clone/lib/lib a 
$ git checkout master 
hack ... 





(2) 执行 提交 。 





$ git commit 





(3) 查看 状态 ， 会 看 到 相对 于 远程 分 文 领先 一 个 提交 。 





$ git status 

# On branch master 

# Your branch is ahead of 'origin/master' by 1 commit. 
# 

nothing to commit (working directory clean) 





在 git status 的 状态 输出 中 ， 可 以 看 出 新 提交 尚未 推送 到 远程 版 本 
库 。 现 在 暂时 不 推送 ， 看 看 在 super 版 本 库 中 执行 git submodule update 对 
子 模 组 的 有 影响， 具体 操作 过 程 如 下 。 


(4) 先 到 super-clone 版 本 库 查 看 一 下 状态 ， 可 以 看 到 子 模 组 已 修 
改 ， 包 含 了 更 新 的 提交 。 





$ cd /path/to/my/workspace/super-clone/ 

$ git status 

# On branch master 

# Changed but not updated: 

(use "git add <file>..." to update what will be committed) 

(use "git checkout -- <file>,..." to discard changes in working directory) 


# 
# 
# 
# modified: lib/lib a (new commits) 
# 
n 


oO changes added to commit (use "git add" and/or "git commit -a") 





(5) 通过 git submodule stauts 命 令 可 以 看 出 liby/lib_a 子 模 组 指向 了 新 
的 提交 ID (前 面 有 一 个 加 号 ) ， 而 lib/lib_b 子 模 组 状态 正常 (提交 ID 前 


古 一 个 空格 ， 不 是 加 号 也 不 是 减 写 )。 








$ git submodule status 
+5dea2693e5574a6e3b3a59c6b0c68cb08b2c07e9 1ib/1lib a (heads/master) 
3b52a710068edc070e3a386a6efcbdf28bf1bed5 1ib/lib_b (heads/master) 





(6) 这 时 如 果 不 小 心 执行 了 一 次 git submodule update 命 令 ， 会 将 
lib/lib_a 重 新 切换 到 旧 的 指 问 。 





$ git submodule update 
Submodule path 'lib/lib a': checked out '126b18153583d9bee4562f9af6b9706d2e104016 





(7) 执行 git submodule status 命 令 查 看 子 模 组 状态 ， 可 以 看 到 
lib/lib_a 子 模 组 被 重 置 了 。 





$ git submodule status 
126b18153583d9bee4562f9af6b9706d2e104016 1ib/lib a (remotes/origin/HEAD) 
3b52a710068edc070e3a386a6efcbdf28bf1bed5 1ib/lib_b (heads/master) 











么 刚才 在 lib/lib _a 中 的 提交 丢失 了 人 么 ? 实际 上 因为 已 经 提交 到 了 
master 主 线 ， 因 此 提交 没有 丢失 ， 但 是 如 果 有 数据 没有 提交 ， 就 会 造成 
未 提交 数据 的 丢失 。 


(1) 进 到 lib/lib_a 目 录 ， 看 到 工作 区 再 一 次 进入 分 离 头 指针 状态 。 





$ cd lib/lib_a 

$ git branch 

* (no branch) 
master 





(2) 重新 检 出 master 分 支 找 回 之 前 的 提交 





$ git checkout master 

Previous HEAD position was 126b181... add data for libA 
Switched to branch 'master' 

Your branch is ahead of ‘origin/master' by 1 commit. 





现在 如 果 要 将 lib/lib_a 目 录 下 子 模 组 的 改动 记录 到 父 项 目 (super 版 
本 库 ) 中 ， 就 需要 在 父 项 目 中 进行 一 次 提交 才能 实现 。 








(1) 进入 父 项 目 根 目录 查看 状态 。 因 为 Iib/lib_a 的 提交 已 经 恢复 ， 
因此 再 次 显示 为 有 改动 。 











$ cd /path/to/my/workspace/super-clone/ 
$ git status -s 
M lib/lib_a 





(2) 得 看 差异 比较 ， 会 看 到 指 癌 子 模 组 的 gitliink 有 改动 。 





$ git diff 
diff --git a/lib/lib a b/lib/lib a 
index 126b181..5dea269 160000 
-- a/lib/lib_a 
+++ b/lib/lib_a 
@@ -1 +1 @@ 
-Subproject commit 126b18153583d9bee4562f9af6b9706d2e104016 
+Subproject commit 5dea2693e5574a6e3b3a59c6b0c68cb08b2c07e9 





(3) 将 gitlink 的 改动 添加 到 和 暂 存 区 ， 然 后 提交 。 





$ git add -u 
$ git commit -m "submodule lib/lib a upgrade to new version." 





此 时 先 不 要 忙 着 推送 ， 因 为 如 果 此 时 执行 git push 将 super 版 本 库 推 
送 到 远程 版 本 库 ， 会 引发 一 个 问题 。 即 推送 后 的 远程 super 版 本 库 的 子 模 
组 liblib_a 指 向 了 一 个 新 的 提交 ， 而 该 提交 还 在 本 地 的 lib/lib_a 版 本 库 
(尚未 向 上 游 推 送 ) ， 这 会 导致 其 他 人 克隆 super 版 本 库 和 更 新 模 组 时 因 
为 找 不 到 该 子 模 组 版 本 库 相 应 的 提交 而 出 错 。 下 面 就 是 这 类 错误 的 信 














fatal: reference is not a tree: 5dea2693e5574a6e3b3a59c6boc68cb08b2c07e9 
Unable to checkout '5dea2693e5574a6e3b3a59c6boc68cb08b2c0o7e9' in submodule path 
'1ib/lib a' 





为 了 避免 这 种 可 能 性 的 发 生 ， 最 好 先 推送 lib/lib_a 中 的 新 提交 ， 然 
后 再 向 super 版 本 库 推送 更 新 的 子 模 组 gitlink 改 动 。 即 : 


(1) 先 推 送 子 模 组 。 





$ cd /path/to/my/workspace/super-clone/lib/lib a 
$ git push 





(2) 再 推送 父 版 本 库 。 





$ cd /path/to/my/workspace/super-clone/ 
$ git push 





23.4” 隐 性 子 模 组 


我 在 开发 备份 工具 Gistore 中 时 遇 到 一 个 棘手 的 问题 ， 就 是 隐 性 子 模 
组 的 问题 。Gistore 备 份 工具 的 原理 是 将 要 备份 的 目录 都 挂 载 (mount) 
在 工作 区 中 ， 然 后 执行 git add。 但 是 如 宁 有 某 个 目录 已 经 被 Git 化 了 ， 就 
只 会 以 子 模 组 的 方式 将 该 目录 添加 进来 ， 而 不 会 添加 该 目录 下 的 文件 。 
对 于 一 个 备份 工具 来 说 ， 这 就 意味 着 备份 没有 成 功 。 具 体操 作 过 程 如 
Ps 

















(1) 例如 当前 super 版 本 库 下 有 两 个 子 模 组 : 





$ cd /path/to/my/workspace/super-clone/ 

$ git submodule status 
126b18153583d9bee4562f9af6b9706d2e104016 1lib/lib a (remotes/origin/HEAD) 
3b52a710068edc070e3a386a6efcbdf28bfibed5 1ib/lib_b (heads/master) 





(2) 然后 创建 一 个 新 目录 others， 并 把 该 目录 用 Git 初 始 化 ， 并 做 


一 次 空 的 提交 。 





$ mkdir others 

$ cd others 

$ git init 

$ git commit --allow-empty -m initial 
[master (root-commit) 90364e1] initial 





(3) 在 others 目 录 下 创建 一 个 文件 newfile。 





$ date > newfile 





(4) 回 到 上 一 级 目录 执行 git status， 看 到 有 一 个 others 目 录 没 有 加 
入 版 本 库 控 制 ， 这 很 自然 。 





cd .. 
git status 
On branch master 
Untracked files: 
(use "git add <file>..." to include in what will be committed) 


others/ 
othing added to commit but untracked files present (use "git add" to track) 


三 半 半 半 亲 亲切 仇 





(5) 但 是 如 果 对 others 目 录 执 行 git add 后 ， 会 发 现 奇怪 的 状态 。 





git add others 
git status 
on branch master 
Changes to be committed: 
(use "git reset HEAD <file>..." to unstage) 


new file: others 
Changed but not updated: 
(use "git add <file>..." to update what will be committed) 
(use "git checkout -- <file>,..." to discard changes in working directory) 
(commit or discard the untracked or modified content in submodules) 


modified: others (untracked content) 


亲 半 和 半 亲 半 半 和 闪 亲 半 半 和 半 亲 亲人 盆 仇 








(6) 看 看 others 目 录 的 添加 方式 ， 就 会 发 现 others 目 录 以 gitlink 的 方 
式 添加 到 版 本 库 中 ， 而 没有 把 该 目录 下 的 文件 添加 到 版 本 库 中 。 





$ git diff --cached 

diff --git a/others b/others 

new file mode 160000 

index 0000000. .90364e1 

--- /dev/null 

+++ b/others 

@@ -0, 0 +1 @@ 

+Subproject commit 90364e1331abc29cc63e994b4d2cfbf7c485e4ad 


二 一 


之 所 以 上 面 的 步骤 (5) 运行 git status 命 令 时 others 出 现 了 两 次 ， 就 
是 因为 目录 others 被 当 作 子 模 组 添加 到 了 父 版 本 库 中 ， 而 且 由 于 others 版 
本 库 本 时 “不 干净 ”， 存 在 尚未 加 入 版 本 控制 的 文件 ， 所 以 又 在 状态 输出 
中 显示 了 子 模 组 包含 改动 的 提示 信息 。 


接 下 来 执行 提交 ， 将 others 目 录 提 交 到 版 本 库 中 。 然 后 当 执 行 git 
submoudle status 命 令 时 会 报错 。 因 为 others 作 为 子 模 组 没有 在 .gitmodules 
文件 中 注册 。 





$ git commit -m "add others as submodule." 

$ git submodule status 
126b18153583d9bee4562f9af6b9706d2e104016 1ib/lib a (remotes/origin/HEAD) 
3b52a710068edc070e3a386a6efcbdf28bfibed5 1ib/lib_b (heads/master) 

No submodule mapping found in .gitmodules for path 'others' 





那么 如 何在 不 破坏 others 版 本 库 的 前 提 下 ， 把 others 目 录 下 的 文件 加 
入 版 本 库 呢 ?” 即 避免 others 以 子 模 组 形式 添加 入 库 ， 具 体操 作 过 程 如 
下 


(1) 先 删 除 以 gitlink 形 式 入 库 的 others 子 模 组 。 





$ git rm --cached others 
rm 'others' 





(2) 查看 当前 状态 。 





$ git status 

# On branch master 

# Changes to be committed: 

# (use "git reset HEAD <file>..." to unstage) 


deleted : others 


Untracked files: 
(use "git add <file>..." to include in what will be committed) 


亲 亲 闪闪 亲 亲 六 


others/ 





(3) 重新 添加 others 目 录 ， 注 意 目 录 后 面 的 斜 线 〈 即 路 径 分 隅 符 ) 
非常 重要 。 





$ git add others/ 





(4) 再 次 查看 状态 ， 看 到 others 下 的 文件 被 添加 a 到 super 版 本 库 中 。 





$ git status 
# On branch master 
# Changes to be committed: 


# (use "git reset HEAD <file>..." to unstage) 
## 

# deleted: others 

# new file: others/newfile 

## 





(5) 执行 提交 。 





$ git commit -m "add contents in others/." 

[master 1egc418] add contents in others/. 

2 files changed, 1 insertions(+), 1 deletions(-) 
delete mode 160000 others 

create mode 100644 others/newfile 





在 上 面 的 操作 过 程 中 ， 首 先 删除 了 库 中 的 others 子 模 组 〈 使 用 -- 
cached 参 数 执 行 删除 ) ; 然后 为 了 添加 others 目 录 下 的 文件 使 用 
了 “others/”( 注 意 others 后 面 的 路 径 分 割 符 “%/”) 。 现 在 查看 一 下 子 模 组 





的 状态 ， 会 看 到 只 显示 出 了 之 前 的 两 个 子 模 组 。 





$ git submodule status 
126b18153583d9bee4562f9af6b9706d2e104016 1ib/lib a (remotes/origin/HEAD) 


3b52a710068edc070e3a386a6efcbdf28bf1bed5 1ib/lib_b (heads/master) 





[1] 参见 本 书 第 7 篇 “第 37 章 Gistore”。 


23.5“ 子 模 组 的 管理 问题 


子 模 组 最 主要 的 一 个 问题 是 不 能 基于 外 部 版 本 库 的 茶 一 个 分 文 进 行 
创建 ， 而 使 得 更 新 后 子 模 组 处 于 非 跟 踊 状 态 ， 不 便于 在 子 模 组 中 进行 代 
码 修改 、 提 交 和 向 外 部 推送 。 尤 其 对 于 因 授 权 或 其 他 原因 将 一 个 版 本 库 
拆 分 为 子 模 组 后 ， 使 用 和 管理 非常 不 方便 。 在 “第 25 瘟 ”Android 式 多 版 
本 库 协 同 ” 一 章 中 可 以 看 到 管理 多 版 本 库 的 另外 一 个 可 行 方案 。 








如 琳 在 局 域 网 内 维护 的 版 本 库 所 引用 的 子 模 组 版 本 库存 在 于 为 外 的 
服务 器 上 ， 甚 至 互联 网 上 ， 克 隆子 版 本 库 束 要 浪费 很 多 时 间 。 而 且 如 果 
子 模 组 指 癌 的 版 本 库 不 在 我 们 的 掌控 之 内 ， 一 旦 需要 对 其 进行 定制 ， 束 
会 因为 无 法 回 远 程 服务 器 推送 提交 而 无 法 实现 定制 。 下 一 半 即 “第 24 
章 ” 子 树 合并 ”会 给 出 针对 这 个 问题 的 解决 方案 。 











第 24 章 “ 子 树 合并 


使 用 子 树 合 并 ， 同 样 可 以 实现 在 一 个 项 目 中 引用 其 他 项 目的 数据 。 
但 是 和 子 模 组 方式 不 同 的 是 ， 使 用 子 树 合并 模式 ， 外 部 的 版 本 库 会 作为 
一 个 目录 被 整个 复制 到 本 版 本 库 中 ， 并 且 复 制 到 本 版 本 库 中 的 子 目 录 下 
的 数据 可 以 和 原版 本 库 数据 建立 跟踪 关联 。 使 用 子 树 合并 模式 ， 对 源 目 
外 部 版 本 库 的 数据 的 访问 和 对 本 版 本 库 数据 的 访问 没有 区 别 ， 也 可 以 对 
其 进行 本 地 修改 ， 并 且 能 够 以 子 树 合并 的 方式 将 外 部 版 本 库 的 新 的 改动 
和 本 地 的 修改 相合 并 。 





24.1 引入 外 部 版 本 库 


为 演示 子 树 合并 至 少 需要 准备 两 个 版 本 库 ， 一 个 是 将 要 被 作为 子 目 
录 引 入 的 版 本 库 util.git， 另 外 一 个 是 主 版 本 库 main.git。 





$ git --git-dir=/path/to/repos/util.git init --bare 
$ git --git-dir=/path/to/repos/main.git init --bare 





在 本 地 检 出 这 两 个 版 本 库 : 





$ cd /path/to/my/workspace 
$ git clone /path/to/repos/util.git 
$ git clone /path/to/repos/main.git 





需要 为 这 两 个 空 版 本 库 添加 些 数据 。 非 常 简 单 ， 每 个 版 本 库 下 只 创 
建 两 个 文件 ， Makefile 和 version。 当 执行 make 命 令 时 显示 version 文 件 的 
内 容 。 对 version 文 件 多 次 提交 以 建立 多 个 提交 历史 。 别 忘 了 在 最 后 使 用 
git push origin master 将 版 本 库 推送 到 远程 版 本 库 中 。 





Makefile 文 件 示例 如 下 。 注 意 第 二 行 前 面 的 空白 是 <TAB> 字 符 ， 而 





all: 
@cat version 





在 之 前 答 试 的 git fetch 命 令 都 是 获取 同一 项 目的 版 本 库 的 内 容 。 其 


实 命令 git fetch 从 哪个 项 目 获 取 数 据 并 没有 什么 限制 ， 因 为 Git 的 版 本 库 
不 像 Subversion 那 样 用 一 个 唯一 的 UUID 标 识 让 Subversion 的 版 本 库 之 间 
势 同 水 火 。 当 然 也 可 以 用 git pull 来 获取 其 他 版 本 库 中 的 提交 ， 但 是 那样 
将 把 两 个 项 目的 文件 彻底 混杂 在 一 起 。 对 于 这 个 示例 来 说 ， 因 为 两 个 项 
目 具 有 同样 的 文件 Makefile 和 version， 使 用 git pull 将 导致 冲突 。 所 以 为 
了 将 不 同 项 目的 版 本 库 引 入 ， 并 在 稍 后 以 子 树 合 并 的 方式 添加 到 一 个 子 
目录 中 ， 需 要 用 git fetch 命 令 从 其 他 版 本 库 获取 数据 ， 具 体操 作 过 程 如 
Ts 











(1) 为 了 便于 以 后 对 外 部 版 本 库 的 跟踪 ， 在 使 用 git fetch 前 ， 先 在 
main 版 本 库 中 注册 远程 版 本 库 util.git。 





$ cd /path/to/my/workspace/main 
$ git remote add util /path/to/repos/util.git 





(2) 查看 注册 的 远程 版 本 库 。 





$ git remote -v 

origin /path/to/repos/main.git/ (fetch) 
origin /path/to/repos/main.git/ (push) 

util /path/to/repos/util.git (fetch) 

util /path/to/repos/util.git (push) 





(3) 执行 git fetch 命 令 获取 util.git 版 本 库 的 提交 ，。 





$ git fetch util 





(4) 查看 分 文 ， 包 括 远程 分 文 。 





$ git branch -a 

* master 
remotes/origin/master 
remotes/util/master 





在 不 同 的 分 支 : master 分 支 和 remotes/util/master 分 支 中 ， 文 件 
version 的 内 容 并 不 相同 ， 因 为 来 自 不 同 的 上 游 版 本 库 。 


` 在 mastet 分 支 中 执行 make 命 令 ， 显 示 的 是 main.git 版 本 库 中 version 


文件 的 内 容 。 





$ make 
main v2010.1 





: 从 util/mastet 远 程 分 支 创 建 一 个 本 地 分 支 util-branch， 并 切换 分 
支 。 





$ git checkout -b util-branch util/master 
Branch util-branch set up to track remote branch master from util. 
Switched to a new branch ‘'util-branch' 





“ 执行 make 命 令 ， 显 示 的 是 util.git 版 本 库 中 version 文 件 的 内 容 。 





$ make 
util] v3.0 





像 这 样 在 main.git 中 引入 util.git 显 然 不 能 满足 需要 ， 因 为 在 main.git 
的 本 地 元 隆 版 本 库 中 ，master 分 文 访问 不 到 只 有 在 util-branch 分 文中 才 出 


现 的 util 版 本 库 数 据 。 这 就 需要 做 进一步 的 工作 ， 将 两 个 版 本 库 的 内 容 
合并 到 一 个 分 文中 。 即 将 util-branch 分 文 的 数据 作为 子 目录 加 入 到 master 
分 文中 。 


24.2 子 目 录 方式 合并 外 部 版 本 库 


下 面 就 用 Git 的 底层 命令 git read-tree、git write-tree 和 git commit-tree 
子 命令 ， 实 现 将 util-branch 分 文 所 包含 的 util.git 版 本 库 的 目录 树 以 子 目 录 
(lib/) 的 形式 添加 到 master 分 文中 。 





先 来 看 看 util-branch 分 支 当 前 的 最 新 提交 ， 记 住 最 新 提交 所 指 问 的 
日 录 树 (tree) ， 即 tree id: 0c743e4。 





$ git cat-file -p util-branch 

tree 0c743e49e11019678c8b345e667504cb789431ae 

parent f21f9c10cc248a4a28bf7790414baba483f1ec15 

author Jiang Xin <jiangxin@ossxp.com> 1288494998 +0800 
committer Jiang Xin <jiangxin@ossxp.com> 1288494998 +0800 
Util v2.0 -> v3.0 





查看 tree 0c743e4 所 包含 的 内 容 ， 会 看 到 两 个 文件 : Makefile 和 


version。 





$ git cat-file -p Qc743e4 
100644 blob 07263ff95b4c94275f4b4735e26ea63b57b3c9e3 Makefile 
100644 blob bebe6bi0Qeb9622597dd2b641iefe8365c3638004e version 





切换 到 master 分 支 ， 以 如 下 方式 调用 git read-tree 将 util-branch 分 支 的 
目录 树 读 取 到 当前 分 支 lib 目 录 下 ， 具 体操 作 过 程 如 下 。 


(1) 切换 到 master 分 支 。 





$ git checkout master 





(2) 执行 git read-tree 命 令 ， 将 分 文 util-branch 读 取 到 当前 分 文 的 一 


a 





$ git read-tree --prefix=lib util-branch 





(3) 调用 git read-tree 只 是 更 新 了 暂 存 区 ， 所 以 查看 工作 区 状态 会 
看 到 工作 区 中 还 不 存在 lb 目录 下 的 两 个 文件 。 











$ git status 

# On branch master 

# Changes to be committed: 

(use "git reset HEAD <file>..." to unstage) 


new file: lib/Makefile 
new file: lib/version 


Changed but not updated: 
(use "git add/rm <file>..." to update what will be committed) 
(use "git checkout -- <file>,..." to discard changes in working directory) 


deleted: lib/Makefile 
deleted: lib/version 


亲 半 闪闪 亲 半 亲 亲 半 半 亲 宁 





(4) 执行 检 出 命令 ， 将 jb 目录 下 的 文件 更 新 出 来 。 





$ git checkout -- 1Lib 








(5) 再 次 查看 状态 ， 会 看 到 前 面 执行 的 git read-tree 命 令 添加 到 了 
暂 存 区 的 文件 中 。 





$ git status 
# On branch master 
# Changes to be committed: 


(use "git reset HEAD <file>..." to unstage) 


new file: lib/Makefile 
new file: lib/version 


亲 亲 半 亲 六 





现在 还 不 能 忙 着 提交 ， 因 为 如 果 现 在 进行 提交 就 体现 不 出 两 个 分 支 
的 合并 关系 。 需 要 使 用 Git 底 层 的 命令 进行 数据 提交 ， 具 体操 作 过 程 如 
Ts 





(1) 调用 git write-tree 将 暂 存 区 的 目录 树 保存 下 来 。 


要 记 住 调用 git write-tree 后 形成 的 新 的 tree-id: 2153518。 





$ git write-tree 
2153518409d218609af40babededec6e8ef51616 





(2) 执行 git cat-file 命 令 显示 这 标 树 的 内 容 ， 会 注意 到 其 中 lib 目 录 
的 tree-id 和 之 前 查看 过 的 util-branch 分 支 最 新 的 提交 对 应 的 tree-id 一 样 都 
是 0c743e4。 





$ git cat-file -p 2153518409d218609af40babededec6e8ef51616 
100644 blob 07263ff95b4c94275f4b4735e26ea63b57b3c9e3 Makefile 
©040000 tree 0c743e49e11019678c8b345e667504cb789431ae 1ib 
100644 blob 638c7b7c6bdbde1id29e0b55b165f755c8c4332b5 version 





(3) 要 手工 创建 一 个 合并 提交 ， 即 新 的 提交 要 有 两 个 父 提 交 。 这 
两 个 父 提 交 分 别 是 master 分 文 和 util-branch 分 文 的 最 新 提交 。 用 下 面 的 命 


令 显 示 两 个 提交 的 提交 ID， 并 记 下 这 两 个 提交 ID。 








$ git rev-parse HEAD 


911b1af2e0c95a2fc1306b8dea707064d5386c2e 
$ git rev-parse util-branch 
12408a149bfa78a4c2d4011f884aa2adb04f0934 





(4) 执行 git commit-tree 命 令 手 动 创建 提交 。 新 提交 的 目录 树 来 自 
上 面 的 git write-tree 产 生 的 目录 树 (tree-id 为 2153518) ， 而 新 提交 ( 合 


并 提交 ) 的 两 个 父 提交 直接 用 上 面 git rev-parse 显 示 的 两 个 提交 ID 表示 。 





$ echo "subtree merge" | \ 
git commit-tree 2153518409d218609af40babededec6e8ef51616 \ 
-p 911b1af2e0c95a2fc1306b8dea707064d5386c2e \ 
-p 12408a149bfa78a4c2d4011f884aa2adb04f0934 
62ae6cc3f9280418bdbofcf6c1e678905b1fe690 








(5) 执行 git commit-tree 命 令 的 输出 是 提交 之 后 产生 的 新 提交 的 提 


交 ID。 需 要 把 当前 的 master 分 文 重 置 到 此 提交 ID。 





$ git reset 62ae6cc3f9280418bdbofcf6c1e678905b1fe690 





(6) 查看 一 下 提交 日 志 及 分 支 图 ， 可 以 看 到 通过 复杂 的 git read- 
tree、 git write-tree 和 git commit-tree 命 令 制造 的 合并 提交 ， 的 确 将 两 个 不 


同 的 版 本 库 合 并 到 一 起 了 。 





$ git log --graph --pretty=oneline 

办 62ae6cc3f9280418bdbofcf6c1e678905b1fe690 subtree merge 

人 | 

| * 12408a149bfa78a4c2d4011f884aa2adb04f0934 Util v2.0 -> v3.0 
| * f21f9c10cc248a4a28bf7790414baba483f1ec15 util] v1.0 -> v2.0 
| * 76dboad729db9fdc5be043f3b4ed94ddc945cd7f util v1.0 

* 911b1af2e0c95a2fc1306b8dea707064d5386c2e main v2010.1 





(7) 看 看 现在 的 master 分 文 。 





$ git cat-file -p HEAD 

tree 2153518409d218609af40babededec6e8ef51616 

parent 911b1af2e0c95a2fc1306b8dea707064d5386c2e 

parent 12408a149bfa78a4c2d4011f884aa2adb04f0934 

author Jiang Xin <jiangxin@ossxp.com> 1288498186 +0800 
committer Jiang Xin <jiangxin@ossxp.com> 1288498186 +0800 
Subtree merge 





(8) 看 看 目录 树 。 





$ git cat-file -p 2153518409d218609af40babededec6e8ef51616 
100644 blob 07263ff95b4c94275f4b4735e26ea63b57b3c9e3 Makefile 
©040000 tree 0c743e49e11019678c8b345e667504cb789431ae lib 
100644 blob 638c7b7c6bdbde1id29e0b55b165f755c8c4332b5 version 








整个 过 程 非常 乏 珊 ， 但 是 不 要 太 过 担心 ， 只 需要 对 原理 了 解 清楚 惑 
可 以 了 ， 因 为 在 后 面 会 介绍 一 个 Git 插 件 ， 它 封装 了 复杂 的 子 树 合并 操 
作 。 


24.3 ”利用 子 树 合并 跟踪 上 游 改 动 


如 果子 树 (ib 目 录 )〉 的 上 游 《 即 util.git) 包含 了 新 的 提交 ， 如 何 将 
util.git 的 新 提交 合并 过 来 呢 ? 这 就 要 用 到 名 为 subtree 的 合并 策略 中 。 








在 执行 子 树 合 并 之 前 ， 先 切换 到 util-branch 分 支 ， 获 取 远 程 版 本 库 
的 改动 。 





$ git checkout util-branch 
$ git pull 

remote: Counting objects: 8, done. 

remote: Compressing objects: 100% (4/4), done. 
remote: Total 6 (delta 0), reused 0 (delta 0) 
Unpacking objects: 100% (6/6), done. 

From /path/to/repos/util 

12408al1..5aba1i4f master -> util/master 

Updating 12408al1. .5aba14f 

Fast-forward 

version | 2 +- 

1 files changed, 1 insertions(+), 1 deletions(-) 
$ git checkout master 





在 切换 回 master 分 支 后 ， 如 果 这 时 执行 git merge util-branch， 会 将 
uitl-branch 的 数据 直接 合并 到 master 分 文 的 根 目 录 下 ， 而 实际 上 是 希望 合 
并 发 生 在 lb 目录 中 ， 这 就 需要 以 如 下 方式 进行 调用 ， 以 subtree 策 略 进 行 
合并 。 








如 果 Git 的 版 本 小 于 1.7， 直 接 使 用 subtree 合 并 策略 。 





$ git merge -s subtree util-branch 





如 果 Git 的 版 本 是 1.7 之 后 〈 含 1.7) 的 版 本 ， 则 可 以 使 用 默认 的 
recursive 合 并 策略 ， 通 过 参数 -Xsubtree=<prefix> 在 合并 时 使 用 正确 的 子 
树 进行 匹配 合并 。 避 人 免 了 使 用 subtree 合 并 策略 时 的 猜测 。 





$ git merge -Xsubtree=lib util-branch 





再 来 看 看 执行 子 树 合并 之 后 的 分 文 图 示 。 





$ git log --graph --pretty=oneline 
f1a33e55eea04930a500c18a24a8bd009ecd9ac2 Merge branch "util-branch 
\ 

* 5aba14fd347fc22cd8fbd086c9f26a53276f15c9 util v3.1 -> v3.2 

* a6d53dfcf78e8a874e9132def5ef87a2b2febfa5 util v3.0 -> v3.1 

| 62ae6cc3f9280418bdbofcf6c1e678905b1fe690 subtree merge 


1/ 

* 12408a149bfa78a4c2d4011f884aa2adb04f0934 util v2.0 -> v3.0 
* f21f9c10cc248a4a28bf7790414baba483f1ec15 util v1.0 -> v2.0 
* 76dboad729db9fdc5be043f3b4ed94ddc945cd7f util v1.0 


* 
| 
| 
| 
六 
I\\ 
| 
| 
| 
| 
* 911b1af2e0c95a2fc1306b8dea707064d5386c2e main v2010.1 





[1] 参见 第 3 篇 第 16 章 “16.6 合 并 策略 


24.4 子 树 拆 分 


既然 可 以 将 一 个 代码 库 通 过 子 树 合 并 的 方式 作为 子 目 录 加 入 到 另外 
一 个 版 本 库 中 ， 反 之 也 可 以 将 一 个 代码 库 的 子 目录 独立 出 来 转换 为 力 外 
的 版 本 库 。 不 过 这 个 反 向 过 程 非常 复杂 。 要 将 一 个 版 本 库 的 子 目录 作为 
顶级 目录 导出 到 为 外 的 项 目 ， 潜 藏 的 条 件 是 要 导出 历史 ， 因 为 如 果 不 关 
心 历 史 ， 直 接 拷贝 文件 重建 项 目 就 可 以 了 。 子 树 拆 分 的 大 致 过 程 是 : 

















(1) 找到 要 导出 的 目录 的 提交 历史 ， 并 反 辐 排序 。 


(2) 依次 对 每 个 提交 执行 下 面 的 操作 。 





(3) 找 出 提交 中 导出 目录 对 应 的 tree id。 
(4) 对 该 tree id 执行 git commit-tree。 


(5) 执行 git commit-tree 要 保持 提交 信息 还 要 重新 设置 提交 的 


parents。 





手工 执行 这 个 操作 复杂 且 易 出 错 ， 可 以 用 下 节 介 绍 的 git-subtree 插 
件 ， 或 使 用 第 6 篇 第 35 章 的 “35.4Git 版 本 库 整 理 ” 一 节 中 介绍 的 git filter- 
branch 子 目录 过 滤 右 的 技术 。 





24.5 ”git-subtree 搬 件 


git-subtree 插 件 所 用 shell 脚 本 开发 ， 安 装 之 后 为 Git 提 供 了 新 的 git 
subtree 命 令 ， 文 持 前 面 介 绍 的 子 树 合并 和 子 树 拆 分 。 命 令 非常 简单 易 
用 ， 将 其 他 版 本 库 以 子 树 形式 导 入 ， 再 也 不 必 和 底 层 的 Git 命 令 打 交道 
本 


安装 Git subtree 很 简单 ， 操 作 如 下 : 





$ git clone git://github.com/apenwarr/git-subtree.git 
$ cd git-subtree 

$ make doc 

$ make test 

$ sudo make install 





下 面 就 来 介绍 Git subtree 的 常用 命令 。 
1.git subtree add 


命令 git subtree add 相 当 于 将 其 他 版 本 库 以 子 树 方式 加 入 到 当前 版 本 
库 。 用 法 如 下 : 





git subtree add [--squash] -P <prefix> <commit> 
git subtree add [--squash] -P <prefix> <repository> <refspec> 





其 中 可 选 的 --squash 的 含义 是 压缩 为 一 个 版 本 后 再 添加 。 





对 于 文中 的 示例 ， 为 了 将 util.git 合 并 到 main.git 的 lib 目 录 ， 可 以 直接 
这 样 调用 : 





$ git subtree add -P lib /path/to/repos/util.git master 








不 过 推荐 的 方法 还 是 先 在 本 地 建 YYutil.git 版 本 库 的 退 踪 分 文 。 





$ git remote add util /path/to/repos/util.git 
$ git fetch util 

$ git branch util-branch util/master 

$ git subtree add -P lib util-branch 





2.git subtree merge 


命令 git subtree merge 相 当 于 将 子 树 对 应 的 远程 分 支 的 更 新 重新 合并 
到 子 树 中 ， 相 当 于 完成 了 git merge-s subtree 操 作 ， 用 法 如 下 : 





git subtree merge [--squash] -P <prefix> <commit> 





其 中 可 选 的 --squash 的 含义 是 压缩 为 一 个 版 本 后 再 合并 。 


对 于 文章 中 的 示例 ， 为 了 将 util-branch 分 支 包 含 的 上 游 的 最 新 改动 
合并 到 master 分 支 的 lib 目 录 中 ， 可 以 直接 这 样 调 用 : 





$ git subtree merge -P lib util-branch 





3.git subtree pull 


命令 git subtree pull 相 当 于 先 对 子 树 对 应 的 远程 版 本 库 执行 一 次 git 
fetch 操 作 ， 然 后 再 执行 git subtree merge。 用 法 如 下 : 





git subtree pull [--squash] -P <prefix> <repository> <refspec...> 





对 于 文章 中 的 示例 ， 为 了 将 util.git 版 本 库 的 master 分 支 包含 的 最 新 
改动 合并 到 master 分 文 的 lib 目 录 中 。 可 以 直接 这 样 调用 : 





git subtree pull [--squash] -P <prefix> <repository> <refspec...> 





更 喜欢 用 前 面 介绍 的 git subtree merge 命 令 ， 因 为 git subtree pull 存 在 
版 本 库 地 址 写 错 的 风险 。 


4.git subtree split 


命令 git subtree split 相 当 于 将 目录 拆 分 为 独立 的 分 文 ， 即 子 树 拆 分 。 
拆 分 后 形成 的 分 文 可 以 推送 到 一 个 新 的 版 本 库 中 ， 进 而 实现 用 原版 本 库 
的 一 个 子 目 录 为 根 目录 创建 出 新 的 版 本 库 。 用 法 如 下 : 














git subtree split -P <prefix> [--branch <branch>] [--onto ...] [--ignore-joins] 
[--rejoin] <commit...> 





子 树 拆 分 后 的 最 后 一 个 commit-id。 这 样 可 以 通过 
令 


仿 ， 如 pit subtree Push 命令 。 


. 参数 --branch 提 供 拆 分 后 创建 的 分 支 名 称 。 如 果 不 提供 ， 


了 


过 git subttee split 命 令 提 供 的 提交 ID 得 到 拆 分 的 结 


和 参数--onto 和 参数 将 目录 拆 分 附加 于 已 经 存在 的 提交 上 。 


Se 


a 


Se 


策略 ， 不 会 破坏 当前 分 支 。 


5.git subtree push 


数 --ignote-joins 忽 略 对 之 前 拆 分 历史 的 检查 。 


. 参数 --rejoin 会 将 拆 分 结果 合并 到 当前 分 支 ， 因 为 采用 ours 的 合并 


命令 git subtree push 先 执行 子 树 拆 分 ， 再 将 拆 分 的 分 文 推 送 到 远程 


服务 器 。 用 法 如 下 : 





git subtree push -P <prefix> <repository> <refspec...> 





该 命令 的 用 法 和 git subtree split 的 类 似 ， 这 里 就 不 再 碍 述 。 


[1] http:/ /github.com/apenwatt/ git-subtree/ 


第 25 章 Android 式 多 版 本 库 协 同 


Android 是 谷歌 (Google〉 开发 的 适合 手持 设备 的 操作 系统 ， 提 供 
了 当前 最 吸引 眼球 的 开源 的 手持 设备 操作 平台 ， 大 有 超越 苹果 
(Apple.com) 专 有 的 iOS 系 统 的 趋势 。 而 Android 的 源 代 码 就 是 使 用 Git 
进行 维护 的 。Android 项 目 在 使 用 Git 进 行 源 代码 管理 上 有 两 个 伟大 的 创 
造 ， 一 个 是 用 Java 开 发 的 名 为 Gerrit 的 代码 审核 服务 器 (将 在 第 5 篇 第 32 


章 专题 介绍 ) ， 另 外 一 个 就 是 本 章 要 重点 介绍 的 repo。 








repo 是 一 个 用 Python 语言 开发 的 命令 行 工 具 ， 可 以 更 方便 地 进行 多 
版 本 库 的 管理 。 先 来 看 看 Android 到 底 包 含 了 多 少 个 Git 库 : 


* Android 的 版 本 库 管理 工具 repo。 





git://android.git,.kernel.org/tools/repo.git 


` 保存 GPS 配置 文件 的 版 本 库 。 





git://android.git,.kernel.org/device/common.git 





. 160 多 个 其 他 的 版 本 库 (截至 2010 年 10 月 ) 。 


如 果 把 160 多 个 版 本 库 都 列 在 这 里 ， 荡 介 各 位 的 下 巴 都 会 掉 下 来 。 
那么 为 什么 Android 的 版 本 库 会 有 这 么 多 呢 ? 怎么 管理 这 么 复杂 的 版 本 


库 呢 ? 








Android 版 本 库 众 多 的 原因 ， 主 要 是 版 本 库 太 大 ， 以 及 Git 不 能 部 分 
检 出 。Android 的 版 本 库 有 接近 2 个 GB 之 大 。 如 果 把 所 有 的 东西 都 放 在 
一 个 库 中 ， 而 某 个 开发 团队 感 兴趣 的 可 能 就 是 某 个 驱动 ， 或 者 是 某 个 应 
用 ， 却 要 下 载 如 此 庞大 的 版 本 库 ， 是 有 些 说 不 过 去 。 








好 了 ， 既 然 接 受 了 Android 有 多 达 160 多 个 版 本 库 这 一 事实 ， 那 么 
Android 是 不 是 用 之 前 介绍 的 “ 子 模 组 ”方式 组 织 起 来 的 呢 ? 如 果真 的 
用 “ 子 模 组 ”方式 来 管理 这 160 多 个 代码 库 ， 可 能 就 需要 如 此 管理 : 





` 建立 一 个 索引 版 本 库 ， 在 该 版 本 库 中 ， 通 过 子 模 组 方式 ， 将 目录 
一 个 一 个 地 对 应 到 这 160 多 个 版 本 库 。 


. 对 此 索引 版 本 库 执行 克隆 操作 后 ， 再 执行 git submodule init 命 令 。 


. 当 执 行 git submodule update 命 令 时 ， 开 始 分 别克 隆 这 160 多 个 版 本 


` 如 果 想 修改 某 个 版 本 库 中 的 内 容 ， 需 要 进入 到 相应 的 子 模 组 目 
录 ， 执 行 切换 分 支 的 操作 。 因 为 子 模 组 是 以 某 个 固定 提交 的 状态 存在 
的 ， 是 不 能 更 改 的 ， 必 须 先 切 换 到 某 个 工作 分 支 后， 才能 进行 修改 和 提 


> 
一 > 一 


全。o 


` 如 果 要 将 所 有 的 子 模 组 都 切换 到 某 个 分 支 (如 mastef) 进行 修 


改 ， 必 须 自 己 通过 脚本 对 这 160 多 个 版 本 库 一 一 进行 切 挽 。 


. Andtoid 有 多 个 版 本 : andtoid-1.0、andtoid-1.5、 ………: 、andtoid- 
2.2_r1.3…… 如 何 维护 这 么 多 的 版 本 呢 ? 也 许 索引 库 要 通过 分 支 和 里 程 
碑 ， 与 子 模 组 的 各 个 不 同 的 提交 状态 进行 对 应 。 但 是 由 于 子 模 组 的 状态 


只 是 一 个 提交 ID， 如 何 能 够 动态 地 指定 到 分 支 ， 真 的 给 不 出 答案 。 


幸好 上 面 只 是 假设 。 聪 明 的 Android 程 序 设 计 师 一 早 就 考虑 到 了 Git 
子 模 组 的 局 限 性 ， 以 及 多 版 本 库 管 理 的 问题 ， 开 发 出 了 repo 这 一 工具 。 





关于 repo 有 这 么 一 则 小 故事 : Android 之 父 安 迪 :和 鲁 宾 在 回应 乔布斯 
关于 Android 太 开放 导致 开发 维护 更 麻烦 的 言论 时 ， 在 Twitter 上 留 了 
下 面 这 段 简短 的 话 : 





the definition of open: "mkdir android ; cd android ; repo init -u 
git://android.git,.kernel.org/platform/manifest.git ; repo Sync ; make" 





是 的 ， 就 是 repo 让 Android 的 开发 变 得 如 此 简单 。 


[1] http:/ /twitter.com/ Arubin 


25.1 ”关于 repo 


repo 是 Google 开 发 的 用 于 管理 Android 版 本 库 的 一 个 工具 。repo 并 不 
是 用 于 取代 Git， 而 是 用 Python 对 Git 进 行 了 一 定 的 封装 ， 简 化 了 对 多 个 
Git 版 本 库 的 管理 。 对 于 repo 管 理 的 任何 一 个 版 本 库 ， 都 需要 使 用 Git 命 
令 进 行 操作 。 


repo 的 使 用 过 程 大 致 如 下 : 


(1) 运行 repo init 命 令 ， 克 隆 Android 的 一 个 清单 库 。 这 个 清单 库 和 
前 面 假设 的 “ 子 模 组 ”方式 工作 的 索引 库 不 同 ， 是 通过 XML 技 术 建 立 的 版 
本 库 清单 。 





(2) 清单 库 中 的 manifest.xml 文 件 ， 列 出 了 160 多 个 版 本 库 的 元 隆 
方式 。 包 括 版 本 库 的 地 址 和 工作 区 地 址 的 对 应 关系 ， 以 及 分 支 的 对 应 关 
系 。 


(3) 运行 repo sync 命 令 ， 开 始 同 步 ， 即 分 别克 隆 这 160 多 个 版 本 库 
到 本 地 的 工作 区 中 。 


(4) 同时 对 160 多 个 版 本 库 执 行 切换 分 文 操 作 ， 切 换 到 茶 个 分 文 。 


25.2 ”安装 repo 


首先 下 载 repo 的 引导 脚本 ， 可 以 使 用 wget、curl 甚 至 浏览 器 从 
http://android.git.kernel.org/repo 上 下 载 。 把 repo 脚 本 设置 为 可 执行 ， 并 复 
制 到 可 执行 的 路 径 中 。 在 Linux 上 可 以 用 下 面 的 指令 将 repo 下 载 并 复制 到 
用 户主 目录 的 bin 目 录 下 。 





$ curl -L -k http://android.git.kernel.org/repo >~/bin/repo 
$ chmod a+x ~/bin/repo 





为 什么 说 下 载 的 repo 只 是 一 个 引导 脚本 (bootstrap) 而 不 是 直接 称 
为 repo 呢 ? 因为 repo 的 大 部 分 功能 代码 不 在 其 中 ， 下 载 的 只 是 一 个 帮助 
完成 整个 repo 程 序 继续 下 载 和 加 载 的 工具 。 如 果 您 是 一 个 程序 员 ， 对 
repo 的 执行 比较 好 奇 ， 可 以 一 起 来 分 析 一 下 repo 引 导 脚 本 。 人 否则 可 以 直 
接 跳 到 下 一 节 。 


看 看 rep0 引 导 脚 本 的 前 儿 行 ( 为 方便 描述 ， 把 注释 和 版 权 信息 过 渡 
掉 了 ) ， 会 发 现 一 个 神奇 的 魔法 : 








1 #!/bin/sh 

2 

3 REPO_URL='git://android.git.kernel.org/tools/repo.git' 
4 REPO_REV="'stable' 

5 

6 magic='--calling-python-from-/bin/sh--'" 
7 Wr exec" python -E "$0" "$@" I "#$magic" 
8 if name == '_ main _' 

9 import sys 
10 if sys.argv[-1] == '#%s' % magic: 
11 del sys.argv[-1] 


12 del magic 





repo 引 导 脚 本 是 用 什么 语言 开发 的 ?这 是 一 个 问题 。 


第 1 行 ， 有 经 验 的 Linux 开 发 者 会 知道 此 脚本 是 用 Shell 脚 本 语言 开 
发 的 。 


第 7 行 ， 是 这 个 魔法 的 最 神奇 之 处 。 有 既是 一 条 合法 的 shell 语 和 句 ， 


第 
又 是 一 条 合法 的 python 语 和 句 。 


第 7 行 如 果 作 为 shel 语 多， 执行 exec， 用 Python 调用 本 脚本 ， 并 替 
换 本 进程 。 三 引号 在 这 里 相当 于 一 个 空 字 串 和 一 个 单独 的 引号 。 


第 7 行 如 果 作 为 python 语 多 ， 三 引号 定义 的 是 一 个 字符 串 ， 字 符 
串 后 面 是 一 个 注释 。 
. 实际 上 第 1 行 到 第 7 行 ， 既 是 合法 的 shell 语 名 又 是 合法 的 python 语 


多。 从 第 8 行 开始 后 面 都 是 python 脚 本 了 。 


. repo 引 导 脚 本 无 论 是 用 shell 执 行 ， 还 是 用 python 执 行 ， 效 果 都 相 
当 于 使 用 python 执 行 此 脚本 。 


repo 脚 本 的 真正 位 置 在 哪里 ? 可 以 通过 分 析 引 导 脚 本 repo 得 到 。 在 
引导 脚本 repo 的 main 函 数 中 ， 首 先 调用 _FindRepo 函 数 ， 从 当前 目录 开 
始 依次 向 上 递归 查找 .reporepo/main.py 文 件 。 





def main(orig_ args): 
main, dir = _FindRepo() 





函数 _FindRepo 返 回 找到 的 .repo/repo/main.py 肢 本 文件 ， 以 及 包含 
repo/main.py 的 .repo 目 录 。 如 果 找 到 了 .repo/repo/main.py 肢 本， 则 把 程序 
的 控制 权 交 给 .repo/repo/main.py 肢 本 (省略 了 在 repo 开 发 库 中 执行 情况 
的 判断 ) 。 


在 下 载 repo 引 导 脚 本 后 ， 没 有 初始 化 之 前 ， 当 然 不 会 存 
在 .repo/repo/main.py 肢 本， 这 时 必须 进行 初始 化 操作 。 





25.3 ”repo 和 清单 库 的 初始 化 


下 载 并 保存 repo 引 导 脚 本 后 ， 建 立 一 个 工作 目录 ， 这 个 工作 目录 将 
作为 Android 的 工作 区 目录 。 在 工作 目录 中 执行 repo init-u<url>， 完 成 
repo 完 整 的 下 载 及 项 目 清单 版 本 库 (manifest.git) 的 下 载 。 

















$ mkdir working-directory-name 
$ cd working-directory-name 
$ repo init -u git://android.git.kernel.org/platform/manifest.git 





命令 repo init 要 完成 如 下 操作 : 


` 完成 repo 这 一 工具 的 完整 下 载 ， 因 为 现在 有 的 不 过 是 repo 的 引导 
程序 。 





初始 化 操作 会 从 android 的 代码 中 克隆 repo.git 库 到 当前 目录 下 
的 .repo/repo 目 录 下 。 在 完成 repo.git 克 隆之 后 ，repo init 命 令 会 将 控制 权 
交 给 工作 区 的 .repo/repo/main.py， 这 个 刚刚 从 repo.git 库 克隆 来 的 脚本 文 
件 ， 继 续 进 行 初始 化 。 


. 克隆 android 的 清单 库 manifest.git (地 址 来 自 于 -u 参 数 ) 。 


“ 克隆 的 清单 库 位 于 .repo/manifests.git 中 ， 本 地 克隆 


到 .repo/manifests。 清单 文件 .repo/manifest.xml 只 是 符号 链接 ， 它 指 


向 .repo/manifests/default.xml。 


` 询问 用 户 的 姓名 和 邮件 地 址 ， 如 果 和 和 Git 默认 的 用 户 名 、 邮 件 地 
址 不 同 ， 则 记录 在 .repo/manifests.git 库 的 config 文 件 中 。 


命令 repo init 还 可 以 附带 --mirror 参 数 ， 以 建立 和 上 游 Android 的 版 
本 库 一 模 一 样 的 镜像 。 这 会 在 后 面 的 章节 介绍 。 


1. 从 哪里 下 载 repo.git? 


在 repo 引 导 脚 本 的 前 几 行 ， 定 义 了 默认 的 repo.git 的 版 本 库 位 置 及 要 
检 出 的 默认 分 支 。 





REPO_URL='git://android.git.kernel.org/tools/repo.git'" 
REPO_REV="' stable' 





如 果 不 想 从 默认 URL 地 址 中 获取 repo， 或 者 不 想 获 取 稳定 版 (stable 
分 文 ) 的 repo， 可 以 在 repo init 子 命令 中 通过 下 面 的 参数 履 新 默认 的 设 
置 ， 从 指定 的 源 地 址 克隆 repo 代 码 库 : 


` 参数 --repo-url， 用 于 设 定 repo 的 版 本 库 地 址 。 
* 参数 --repo-branch， 用 于 设 定 要 检 出 的 分 支 。 


. 参数 --no-repo-verify， 设 定 不 要 对 repo 的 里 程 碑 签 行 严 格 的 验 


十 。 


实际 上 ， 完 成 repo.git 版 本 库 的 区 隆 ， 这 个 repo 引 导 脚 本 束 江 即 才 尽 
了 ，repo init 命 令 的 后 续 处 理 〈 以 及 其 他 子 命令 ) 都 交 给 刚刚 元 隆 出 来 
的 .repo/repo/main.py 来 继续 执行 。 


2. 清 单 库 是 什么 ?从 哪里 下 载 ? 


清单 库 实 际 上 只 包含 一 个 default.xml 文 件 。 这 个 XML 文 件 定 义 了 多 
个 版 本 库 和 本 地 地 址 的 映射 关系 ， 是 repo 工 作 的 指引 文件 。 所 以 在 使 用 
repo 引 导 脚 本 进行 初始 化 的 时 候 ， 必 须 通 过 -u 参 数 指定 清单 库 的 源 地 
址 。 


清单 库 的 下 载 ， 是 通过 repo init 命 令 初始 化 时 ， 用 -u 参 数 指定 清单 库 
的 位 置 。 例 如 repo 针 对 Android 代 码 库 进行 初始 化 时 执行 的 命令 : 





$ repo init -u git://android.git.kernel.org/platform/manifest.git 





repo 引 导 脚 本 的 init 子 命令 可 以 使 用 下 列 和 清单 库 相 关 的 参数 : 


> 


参数 -u (--manifest-url) : 清单 库 的 Git 服 务 器 地 址 。 


. 参数 -b (--manifest-branch) : 检 出 清单 库 的 特定 分 支 


. 参数 --mirror: 只 在 tepo 第 一 次 初始 化 的 时 候 使 用 ， 以 和 Andtoid 服 
务 器 同样 的 结构 在 本 地 建立 镜像 。 


. 参数 -m (--manifest-name) : 当 有 多 个 清单 文件 时 ， 可 以 指定 清 
单 库 的 某 个 清单 文件 为 有 效 的 清单 文件 。 默 认为 defaultxml。 
repo 初 始 化 命令 〈repo init) 可 以 执行 多 次 : 
. 不 带 参数 地 执行 repo init， 从 上 游 的 清单 库 获 取 新 的 清单 文件 


default.xml。 


. 使 用 参数 -u (--manifest-url) 执行 repo init， 会 重新 设 定 上 游 的 清 


单 库 地 址 ， 并 重新 同步 。 


. 使 用 参数 -b (--manifestbtanch) 执行 repo init， 会 使 用 清单 库 的 不 
同 分 支 ， 以 便 在 使 用 tepo sync 时 将 项 目 同步 到 不 同 的 里 程 碑 。 


. 但 是 不 能 使 用 --mittot 命 令 ， 该 命名 只 能 在 第 一 次 初始 化 时 执行 。 
那么 如 何 将 已 经 按照 工作 区 模式 同步 的 版 本 库 转 挽 为 镜像 模式 呢 ? 后 面 


会 看 到 一 个 解决 方案 。 


25.4 清单 库 和 清单 文件 


执行 完 repo init 之 后 ， 工 作 目 录 内 空空 如 也 。 实 际 上 有 一 个 .repo 目 
录 。 在 该 目录 下 除了 一 个 包含 repo 实 现 的 repo 库 克隆 外 ， 就 是 manifest 库 
的 克隆 ， 以 及 一 个 符号 链接 ， 链 接 到 清单 库 中 的 default.xml 文 件 。 





$ 1s -1lF .repo/ 

drwxr-xr-x 3 jiangxin jiangxin 4096 2010-10-11 18:57 manifests/ 
drwxr-xr-x 8 jiangxin jiangxin 4096 2010-10-11 10:08 manifests.git/ 
Jrwxrwxrwx 1 jiangxin jiangxin 21 2010-10-11 10:07 manifest.xml -> 
manifests/default .xml 

drwxr-xr-x 7 jiangxin jiangxin 4096 2010-10-11 10:07 repo/ 








在 工作 目录 下 的 .repo/manifest.xml 文 件 就 是 Android 项 目的 众多 版 本 
库 的 清单 文件 。repo 命 令 的 操作 都 要 参考 这 个 清单 文件 。 


打开 清单 文件 会 看 到 如 下 内 容 : 





<?xml1 version="1.0" encoding="UTF-8"?> 
<manifest> 
<remote name="korg" 
fetch="git://android.git.kernel.org/" 
review="review,.source.android.com" /> 
<default revision="master" 
remote="korg" /> 


<project path="build" name="platform/build"> 
<copyfile src="core/root.mk" dest="Makefile" /> 
</project> 


Ppp 
ONFReoo DO 和 上 人 wN 


<project path="bionic" name="platform/bionic" /> 


181 </manifest> 





这 个 文件 不 太 复 杂 ， 是 吗 ? 


: 这 个 XML 的 顶级 元 素 是 manifest， 见 第 2 行 和 第 181 行 。 


. 第 3 行 通过 一 个 remote 元 素 ， 定 义 了 名 为 korg (ketnelotg 缩 写 ) 的 
远程 版 本 库 ， 其 Git 库 的 基 址 为 git://android.git.kernel.org/。 还 定义 了 代 
码 审 核 服务 器 的 地 址 teview.soutce.andtoid.com。 还 可 以 定义 更 多 的 femote 


元 素 ， 这 里 只 定义 了 一 个 。 


. 第 6 行 用 于 设置 各 个 项 目 默 认 的 远程 版 本 库 (remote) 为 korg， 默 
认 的 分 支 为 master。 当 然 各 个 项 目 (project 元 素 ) 可 以 定义 自己 的 remote 
和 ftevision 履 盖 该 默认 配置 。 


第 9 行 定 义 了 一 个 项 目 ， 该 项 目的 远程 版 本 库 相 对 路 径 为 : 
platform/build， 在 工作 区 克隆 的 位 置 为 : build。 


第 10 行 ， 即 ptoject 元 素 的 子 元 素 copyfile， 定 义 了 项 目 克隆 后 的 一 


个 附加 动作 : 从 cote/rootmk 找 贝 文 件 至 Makefile。 


第 13 行 后 续 的 100 多 行 定义 了 其 他 160 个 项 目 ， 都 是 采用 类 似 的 
project 元 素 语 法 。name 参 数 定义 远程 版 本 库 的 相对 路 径 ，path 参 数 定义 
克隆 到 本 地 工作 区 的 路 径 。 


. 还 可 以 出 现 manifest-setvet 元 素 ， 其 utl 属 性 定义 了 通过 XMLRPC 提 
供 实 时 更 新 清单 的 服务 器 URL。 只 有 当 执 行 repo sync--smatt-sync 的 时 候 
才 会 检查 该 值 ， 并 用 动态 获取 的 manifest 履 盖 掉 默认 的 清单 。 


25.5 同步 项 目 





在 工作 区 执行 下 面 的 命令 ， 会 参照 .repo/manifest.xml 清 单 文件 ， 将 
项 目 所 有 相关 的 版 本 库 全 部 克隆 出 来 。 不 过 最 好 请 在 读 完 本 节 内 容 之 后 


再 尝试 执行 这 条 命令 。 








$ repo sync 





对 于 Android， 这 个 操作 需要 通过 网 络 传递 接近 2 个 GB 的 内 容 ， 如 
果 带 宽 不 是 很 高 的 话 ， 可 能 会 花 掉 几 个 小 时 甚至 是 一 天 的 时 间 。 





也 可 以 仅 克 隆 感 兴趣 的 项 目 ， 在 repo sync 后 面 跟 上 项 目的 名 称 。 项 
目的 名 称 来 自 于 .repo/manifest.xml 这 个 XML 文件 中 project 元 素 的 name 属 
性 值 。 例 如 克隆 platform/build 项 目 : 





$ repo sync platform/build 





repo 有 一 个 功能 可 以 在 这 里 展示 ， 就 是 repo 文 持 通过 本 地 清单 对 默 
认 的 清单 文件 进行 补充 及 蓝 盖 。 即 可 以 在 .repo 目 录 下 创建 
local_manifest.xml 文 件 ， 其 内 容 会 和 .repo/manifest.xml 文 件 的 内 容 进行 
合并 。 





在 工作 目录 下 运行 下 面 的 命令 可 以 创建 一 个 本 地 清单 文件 。 这 个 本 


地 定制 的 清单 文件 来 自 默 认 文件 ， 但 是 删除 了 remote 元 素 和 default 元 
素 ， 并 将 所 有 的 project 元 素 都 重 命 名 为 remove-project 元 素 。 这 实际 相当 
于 对 原 有 的 清单 文件 “ 取 反 ”。 








$ curl -L -k \ 
http://www.ossxp.com/doc/gotgit/download/ch25/manifest-revert.xslt \ 
> manifest-revert.xslt 

$ xsltproc manifest-revert.xslt .repo/manifest.xml > .repo/local manifest.xml 





用 下 面 的 这 条 命令 可 以 看 到 repo 运 行 时 实际 获取 到 的 清单 。 这 个 清 
单 来 自 于 .repo/manifest.xml 和 .repo/local_manifest.xml 两 个 文件 的 汇总 。 





$ repo manifest -0 - 








当 执 行 repo sync 命 令 时 ， 实 际 上 就 是 依据 合并 后 的 清单 文件 进行 同 
步 。 如 果 清 单 中 的 项 目 被 日 定义 清单 全 部 “ 取 反 *， 执 行 同步 就 不 会 同步 
任何 项 目 ， 甚 至 会 删除 已 经 完成 同步 的 项 目 。 





本 地 定制 的 清单 文件 local_manifest,xml 支 持 前 面 介 绍 的 清单 文件 的 


所 有 语法 ， 需 要 注意 的 是 : 





` 不 能 出 现 重 复 定 义 的 remote 元 素 。 这 就 是 为 什么 上 面 的 脚本 要 删 


除 来 自 默 认 manifestxml 的 femote 元 素 。 
. 不 能 出 现 default 元 素 ， 因 为 全 局 只 能 有 一 个 。 


` 不 能 出 现 重 复 的 project 定 义 (name 属 性 不 能 相同 ) ， 但 是 可 以 通 


过 temove-ptoject 元 素 将 默认 清单 中 定义 的 ptoject 删 除 然后 再 重新 定义 。 


试 着 编辑 .repo/local_manifest.xzml， 在 其 中 再 添加 几 个 project 元 素 ， 
然后 试 着 用 repo sync 命 令 进 行 同 步 。 


25.6 ”建立 Android 代 码 库 本 地 镜像 


Android 为 企业 提供 一 个 新 的 市 场 ， 无 论 企业 大 小 都 处 于 同一 个 起 
跑 线 上 。 研 究 Android 尤 其 是 Android 系 统 核心 或 驱动 的 开发 ， 首 先 要 做 
的 就 是 通过 本 地 克隆 建立 一 套 Android 版 本 库 管理 机 制 。 因 为 Android 的 
代码 库 是 那么 庞杂 ， 如 果 一 个 开发 团队 每 个 人 都 去 执行 repo init-u， 再 执 
行 repo sync 从 Android 服 务 器 克隆 版 本 库 的 话 ， 多 大 的 网 络 带 宽 恐 怕 都 不 
够 用 。 唯 一 的 办 法 是 在 本 地 建立 一 个 Android 版 本 库 的 镜像 。 


建立 本 地 镜像 非 第 简单 ， 就 是 在 执行 repo init-u 初 始 化 的 时 候 ， 附 带 


上 上 --mirror 参 数 。 





$ mkdir android-mirror-dir 
$ cd android-mirror-dir 
$ repo init --mirror -u git://android.git,.kernel.org/platform/manifest.git 


之 后 执行 repo sync 就 可 以 从 安装 Android 的 Git 服 务 器 方式 来 组 织 版 
本 库 ， 创 建 一 个 Android 版 本 库 镜 像 了 。 


实际 上 附带 了 --mirror 参 数 执行 repo init-u 命 令 ， 会 在 克隆 


的 .repo/manifests.git 下 的 config 中 记录 配置 信息 : 


[repo] 
mirror = true 


1. 从 Android 的 工作 区 到 代码 库 镜 像 


在 初始 化 repo 工 作 区 时 ， 使 用 不 带 --miror 参 数 的 repo initru， 并 完成 
代码 同步 后 ， 如 果 再 次 执行 repo init 并 附 融 了 --mirror 参 数 ，repo 会 报错 
退出 : “fatal:--mirror not supported on existing client”。 实 际 上 --mirror 参 


数 只 能 对 尚未 初始 化 的 repo 工 作 区 执行 。 





那么 如 果 之 前 没有 用 镜像 的 方法 同步 Android 版 本 库 ， 难 道 要 为 创 
建 代码 库 镜 像 再 重新 执行 一 次 repo 同 步 吗 ? 要 知道 重新 同步 一 份 Android 
版 本 库 是 非常 慢 的 。 我 就 遇 到 了 这 个 问题 。 








不 过 既然 有 manifest.xml 文 件 ， 完 全 可 以 对 工作 区 进行 反 疝 操作， 
将 工作 区 转换 为 镜像 服务 器 的 结构 。 下 面 就 是 一 个 示例 脚本 ， 可 以 从 本 
书 在 Github 上 的 相关 版 本 库 趾 下 载 。 这 个 脚本 利用 了 已 有 的 repo 代 码 进 
行 实现 ， 所 以 看 独 很 简洁 。8-) 


脚本 work2mirror.py 如 下 : 





#!/UsSr/bin/python 

# -*- coding: utf-8 -*- 

import os, Ssys, Shutil 

cwd = os.path.abspath( os.path.dirname( _ file )) 

repodir = os.path.join( cwd, '.repo' ) 

S_repo = 'repo’ 

TRASHDIR = 'old work_tree' 

If not os.path.exists( os.path.join(repodir, S_repo) ): 
print >> sys.stderr, "Must run under repo work_dir root." 
sys.exit(1) 

sys.path.insert( 0, os.path.join(repodir, S repo) ) 

from manifest_ xml import XxmlManifest 

manifest = XmlManifest( repodir ) 

if manifest.IsMirror: 
print >> sys.stderr, "Already mirror, exit." 
sys.exit(1) 


trash = os.path.join( cwd, TRASHDIR ) 
for project in manifest.projects.itervalues(): 

# 将 旧 的 版 本 库 路 径 移 动 到 镜像 模式 下 新 的 版 本 库 路 径 

newgitdir = os.path.join( cwd, '%s.git' % project.name ) 

If os.path.exists( project.gitdir ) and project.gitdir != newgitdir: 
if not os.path.exists( os.path.dirname(newgitdir) ): 

os.makedirs( os.path.dirname(newgitdir) ) 

print "Rename %s to %s,." % (project.gitdir, newgitdir) 
os.rename( project.gitdir, newgitdir ) 

# 将 工作 区 移动 到 待 删除 目录 

if project.worktree and os.path.exists( project.worktree ): 
newworktree = os.path.join( trash, project.relpath ) 
if not os.path.exists( os.path.dirname(newworktree) ): 

os.makedirs( os.path.dirname(newworktree) ) 

print "Move old worktree %s to %s." % (project.worktree, newworktree ) 
os.rename( project.worktree, newworktree ) 

If os.path.exists ( os.path.join( newgitdir, ‘'config' ) ): 
# 修改 版 本 库 的 配 
os.chdir( newgitdir ) 
os.system( "git config core.bare true" 
os.system( "git config remote.korg.fetch '+refs/heads/*:refs/heads/*'" ) 


# 删除 remotes 分 支 ， 因 为 作为 版 本 库 镜 像 不 需要 remote 分 支 
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if os.path.exists ( os,path,join( newgitdir, 'refs', 'remotes' ) ): 
print "Delete " + os.path.join( newgitdir, ‘'refs', 'remotes' ) 
shutil.rmtree( os.path.join( newgitdir, 'refs', ‘'remotes' ) ) 


# 设置 menifest 为 镜像 
mp = manifest.manifestProject 
mp.config.SetString('repo.mirror', "true ') 











使 用 方法 很 简单 ， 只 要 将 脚本 放 在 Android 工 作 区 下 执行 承 可 以 
了 了。 执行 完毕 会 将 原 有 工作 区 的 目录 移动 到 old_work_tree 子 目录 下 ， 在 
确认 原 有 工作 区 没有 未 提交 的 数据 后 ， 直 接 删 除 old_work_ tree 即 可 。 








$ python work2mirror .py 





2. 创 建新 的 清单 库 ， 或 者 修改 原 有 清单 库 


建立 了 Android 代 人 码 库 的 本 地 镜像 后 ， 如 果 不 对 manifest 清 单 版 本 库 
进行 定制 ， 在 使 用 repo sync 同 步 代码 的 时 候 ， 仍 然 使 用 Android 官 方 的 代 
码 库 同步 代码 ， 束 会 使 得 本 地 的 镜像 版 本 库 形 同 虚设 。 解 决 办 法 是 创建 
一 个 自己 的 manifest 库 ， 或 者 在 原 有 清单 库 中 建立 一 个 分 文 加 以 修改 。 











如 果 创 建新 的 清单 库 ， 参 考 Android 上 游 的 manifest 清 单 库 进行 创建 。 


[1] https:/ /github.com/ossxp- 


com/ gotgit/raw/master/download/ ch25/work2mirrot.py 


25.7 repo 的 命令 集 


repo 子 命令 实际 上 是 Git 命 令 的 或 简单 或 复杂 的 封装 。 每 一 个 repo 子 
命令 都 对 应 于 repo 源 人 码 树 中 subcmds 目 录 下 的 一 个 同名 的 Python 文 件 。 
一 个 repo 子 命令 都 可 以 通过 下 面 的 命令 获得 帮助 。 





repo help <command> 








通过 阅读 代码 ， 可 以 更 加 深入 地 了 解 repo 子 命令 的 封装 。 


1.repo init 命 令 





repo init 子 命令 主要 完成 检 出 清单 版 本 库 〈manifest.git) ， 以 及 配置 
Git 用 户 的 用 户 名 和 邮件 地 址 的 工作 。 


实际 上 ， 完 全 可 以 进入 到 .repo/manifests 目 录 ， 用 Git 命 令 操 作 清 单 


库 。 对 manifests 的 修改 不 会 因为 执行 repo init 而 去 失 ， 除 非 是 处 于 未 跟踪 


2.repo Sync 命令 


repo Sync 子 命令 用 于 参照 清单 文件 克隆 或 同步 版 本 库 。 如 果 某 个 项 
目 版 本 库 尚 不 存在 ， 则 执行 repo sync 命 令 相 当 于 执行 git alone。 如 果 项 
目 版 本 库 已 经 存在 ， 则 相当 于 执行 下 面 的 两 个 命令 : 








* git temote update 
相当 于 对 每 一 个 remote 源 执行 fetch 操 作 。 
* git trebase origin/branch 


针对 当前 分 支 的 跟踪 分 支 执行 rebase 操 作 。 不 采用 merge 而 是 采用 
rebase， 目 的 是 减少 提交 数量 、 方 便 评 审 〈Gerrit) 。 


3.repo start 命 令 


repo start 子 命令 实际 上 是 对 git checkout-b 命 令 的 封装 。 为 指定 的 项 
目 或 所 有 项 目 ( 若 使 用 --all 参 数 ) ， 以 清单 文件 中 为 项 目 设 定 的 分 支 或 
里 程 碑 为 基础 ， 创 建 特性 分 支 。 特 性 分 支 的 名 称 由 命令 的 第 一 个 参数 指 
定 。 相 当 于 执行 checkout-b。 


用 法 如 下 : 





repo start <newbranchname> [--all | <project>...] 





4.repo status 命 令 


repo status 子 命令 实际 上 是 对 git diff-index、git diff-files 命 令 的 封 


装 ， 同 时 显示 暂 存 区 的 状态 和 本 地 文件 修改 的 状态 。 





用 法 如 下 : 





repo Status [<project>...] 





示例 输出 : 





project repo/ branch devwork 
-Mm subcmds/status.py 





上 面 的 示例 输出 显示 了 repo 项 目的 devwork 分 支 的 修改 状态 。 
. 每 个 小 节 的 首 行 显示 项 目的 名 称 ， 以 及 所 在 分 支 的 名 称 。 


示 该 项 目 中 文件 的 变更 状态 。 头 两 个 字母 显示 变更 状态 ， 
后 面 显示 文件 名 或 其 他 变更 信息 。 


` 第 一 个 字母 表示 暂 存 区 的 文件 修改 状态 。 
其 实 是 git-diff-index 命 令 输出 中 的 状态 标识 ， 用 大 写 显 示 。 
` -: 没有 政变 
. A: 添加 (不 在 HEAD 中 ,在 暂 存 区 ) 
- M: 修改 (在 HEAD 中 ,在 暂 存 区 ， 内 容 不 同 ) 
` D: 删除 〈 在 HEAD 中 ， 不 在 暂 存 区 ) 


` R: 重 命名 《不 在 HEAD 中 ， 在 暂 存 区 ， 路 径 修改 ) 


CC: 拷贝 (不 在 HEAD 中 ,在 暂 存 区 ， 从 其 他 文件 拷贝 ) 
. 工 : 文件 状态 改变 (在 HEAD 中 ， 在 暂 存 区 ， 内 容 相同 ) 
" U: 未 合并 ， 需 要 冲突 解决 

. 第 二 个 字母 表示 工作 区 文件 的 更 改 状 态 。 

其 实 是 git-diff-files 命 令 输 出 中 的 状态 标识 ， 用 小 写 显示 。 
` -; 新 /未 知 (不 在 暂 存 区 ， 在 工作 区 ) 
 m; 修改 (在 暂 存 区 ， 在 工作 区 ， 被 修改 ) 
qd: 删除 (在 暂 存 区 ， 不 在 工作 区 ) 


“ 两 个 表示 状态 的 字母 后 面 ， 显 示 文 件 名 信息 。 如 果 有 文件 重 命名 


还 会 显示 改变 前 后 的 文件 名 及 文件 的 相似 度 。 
5.repo checkout 命 令 


repo checkout 子 命令 实际 上 是 对 git checkout 命 令 的 封装 。 检 出 之 前 


由 repo start 创 建 的 分 支 。 


用 法 如 下 : 





repo checkout <branchname> [<project>...] 





6.repo branches 命 令 





repo branches 读 取 各 个 项 目的 分 文 列 表 并 汇总 显示 。 该 命令 实际 上 
通过 直接 读 取 .gitrefs 目 录 下 的 引用 来 获取 分 文 列 表 ， 以 及 分 文 的 发 布 状 
态 


大 
态 等 。 





用 法 如 下 : 





repo branches [<project>...] 





输出 示例 : 





*p nocolor | in repo 
repo2 | 





: 第 一 个 字母 若 显示 星 号 (*) ， 则 含义 是 此 分 支 为 当前 分 支 。 


. 第 二 个 字母 若 为 大 写字 母 P， 则 含义 是 分 支 的 所 有 提交 都 发 布 到 
代码 审核 服务 器 上 了 。 


. 第 二 个 字母 若 为 小 写字 母 p， 则 含义 是 只 有 部 分 提交 被 发 布 到 代 


` 若 不 显示 P 或 p， 则 表明 分 支 尚未 发 布 。 
` 第 二 个 字段 为 分 支 名 。 


-第 三 个 字段 为 以 坚 线 (|) 开始 的 字符 囊 ， 表 示 该 分 支 存在 于 哪 


些 项 目 中 。 


* in all projects 


该 分 文 处 于 所 有 项 目 中。 


in ptojectl project2 





该 分 文 只 在 特定 项 目 中 定义 。 如 : project1、project2。 


Dot in projectl 





该 分 文 不 存在 于 这 些 项 目 中 。 即 除了 project1 项 目 外 ， 其 他 项 目 都 


7.repo diff 命 令 


repo diff 子 命令 实际 上 是 对 git diff 命 令 的 封装 ， 用 于 分 别 显示 各 个 
项 目 工作 区 下 的 文件 差异 。 


用 法 如 下 : 





repo diff [<project>...] 





8.repo stage 命 令 


repo stage 子 命令 实际 上 是 对 git add--interactive 命 令 的 封装 ， 用 于 挑 
选 各 个 项 目 工作 区 中 的 改动 修改、 添加 等 ) 以 加 入 暂 存 区 。 


用 法 如 下 : 





repo stage -i [<project>...] 





9.repo upload 命 令 





repo upload 相 当 于 git push， 但 是 又 有 很 大 的 不 同 。 执 行 repo upload 
不 是 将 版 本 库 改动 推送 到 克隆 时 的 远程 服务 器 ， 而 是 推送 到 代码 审查 服 
务 器 (由 Gerrit 软 件 架设 ) 的 特殊 引用 上 ， 使 用 的 是 SSH 协 议 〈“ 特 丈 端 
口 ) 。 代 码 审核 服务 器 会 对 推送 的 提交 进行 特殊 处 理 ， 将 新 的 提交 显示 
为 一 个 待 审核 的 修改 集 ， 并 进入 代码 审查 流程 。 只 有 当 审 核 通 过 后 ， 才 
会 合并 到 官方 正式 的 版 本 库 中 。 





























用 法 如 下 : 
repo upload [--re --cc] {[<project>]... | --replace <project>} 
-h, --help 显示 帮助 信息 。 
-t 发 送 本 地 分 支 名 称 到 Gerrit 代码 审核 服务 器 。 
--replace 发 送 此 分 支 的 更 新 补丁 集 。 注 意 使 用 该 参数 ， 只 能 指定 一 个 项 目 。 
--re=REVIEWERS, --reviewers=REVIEWERS 
要 求 由 指定 的 人 员 进 行 审核 。 



































=-CECC 同时 发 送 通知 到 如 下 邮件 地 址 。 








确定 推送 服务 器 的 端口 


分 文 改动 的 推送 是 发 给 代码 审核 服务 器 ， 而 不 是 下 载 代码 的 服务 
项。 使 用 的 协议 是 SSH 协 议 ， 但 是 使 用 的 并 非 标准 端口 。 如 何 确认 代码 
审核 服务 圳 上 提供 的 特殊 SSH 端 口 呢 ? 


在 执行 repo upload 命 令 时 ，repo 会 通过 访问 代码 审核 Web 服 务 器 
的 /ssh_info 的 Un 获取 SSH 服 务 端口 ， 默 认为 29418。 这 个 端口 ， 就 是 repo 
upload 发 起 推送 的 服务 器 的 SSH 服 务 端 口 。 


修订 集 修 改 后 重新 传送 


只 有 已 经 通过 repo upload 命 令 在 代码 审 碍 服务 器 上 提交 了 一 个 修订 
集 ， 才 会 得 到 一 个 修订 号 。 关 于 此 次 修订 的 相关 讨论 会 发 送 到 提交 者 的 
邮箱 中 。 如 果 修 订 集 有 误 没 有 通过 审核 ， 可 以 重新 修改 代码 ， 再 次 回 代 
码 审核 服务 器 上 传 修订 集 。 


一 个 修订 集 修改 后 再 次 上 传 ， 如 果 修 订 集 的 ID 不 变 那 将 是 非常 有 用 
的 ， 因 为 这 样 相关 的 修订 集 都 在 代码 审核 服务 器 的 同一 个 界面 中 显示 。 


在 执行 repo upload 时 会 弹出 一 个 编辑 界面 ， 提 示 在 方 括号 中 输入 修 
订 集 编号 ， 人 否则 会 在 代码 审查 服务 圳 上 创建 新 的 ID。 有 一 个 办 法 可 以 不 
用 手工 输入 修订 集 ， 如 下 : 


= = = >4 
repo upload --replace project_name 


当 使 用 --replace 参 数 后 ，repo 会 检查 本 地 版 本 库 名 为 
refs/published/branch_name 的 特殊 引用 (上 一 次 提交 的 修订 )， 获 得 其 
对 应 的 提交 SHA1 哈 希 值 。 然 后 在 代码 审核 服务 器 的 refs/changes/ 命 名 空 
间 下 的 特殊 引用 中 寻找 和 提交 SHA1 哈 希 值 匹 配 的 引用 ， 找 到 的 匹配 引 
用 其 名 称 中 就 所 包含 有 变更 集 ID， 直 接 用 此 变更 集 ID 作 为 新 的 变更 集 ID 
提交 到 代码 审核 服务 器 。 








Gerrit 服 务 器 魔法 


repo upload 命 令 执 行 推送 ， 实 际 上 会 以 类 似 如 下 的 命令 行 格式 进行 
调用 : 





git push --receive-pack='gerrit receive-pack --reviewer charlie@example.com' \ 
ssh://review.example.com:29418/project HEAD:refs/for/master 








Gerrit 服 务 器 接收 到 git push 请 求 后 ， 会 自动 将 对 分 支 的 提交 转换 为 
修订 集 ， 显 示 于 Gerrit 的 提交 审核 界面 中 。Gerrit 的 魔法 破解 的 关键 点 就 
在 于 git push 命 令 的 --receive-pack 人 参数。 即 交 由 gerrit-receive-pack 命 令 执 
行 提交 ， 进 入 非 标准 的 git 处 理 流程 ， 将 提交 转换 为 在 refs/changes 命 名 空 
间 下 的 引用 ， 而 不 在 refs/for 命 名 空间 下 创建 引用 。 


10.repo download 命 令 


repo download 命 令 主要 用 于 代码 审核 者 下 载 和 评估 页 献 者 提交 的 修 


订 。 贡 献 者 的 修订 在 Git 版 本 库 中 以 refs/changes/<changeid>/<patchset> 引 
用 方式 命名 (默认 的 patchset 为 1) ， 和 其 他 Git 引 用 一 样 ， 用 git fetch 获 
取 ， 该 引用 所 指向 的 最 新 的 提交 就 是 页 献 者 待 审核 的 修订 。 使 用 repo 
download 命 令 实 际 上 就 是 用 git fetch 获 取 到 对 应 项 目的 
refs/changes/<changeid>/patchset> 引 用 ， 并 上 自动 切换 到 对 应 的 引用 上 。 








用 法 如 下 : 





repo download {project change[/patchset]}... 





11.repo rebase 命 令 


repo rebase 子 命令 实际 上 是 对 git rebase 命 令 的 封装 ， 该 命令 的 参数 


也 作为 git rebase 命 令 的 参数 ， 但 -ji 参数 仅 当 对 一 个 项 目 执行 时 才 有 效 。 



































用 法 如 下 : 

命令 行 : repo rebase {[<project>...] | -i <project>...} 
-h， --help 显示 帮助 并 退出 
-TI， --interactive ”交互 式 的 变 基 【( 仅 对 一 个 项 目 时 有 效 ) 
-f， --force-rebase 向 git rebase 命令 传递 - -force-rebase 参数 
--no-ff 向 git rebase 命令 传递 -no-ff 参数 
-dq, --quiet 向 git rebase 命令 传递 --quiet 参数 
--autosquash 向 git rebase 命令 传递 --autosquash 参数 
--whitespace=WS 向 git rebase 命令 传递 --whitespace 参数 








12.repo prune 命 令 


repo prune 子 命令 实际 上 是 对 git branch-d 命 令 的 封装 ， 该 命令 用 于 扫 


描 项 目的 各 个 分 文 ， 并 删除 已 经 合并 的 分 文 。 


用 法 如 下 : 





repo prune [<project>...] 





13.repo abandon 命 令 


相 比 repo prune 命 令 ，repo abandon 命 令 更 具 破 坏 性 ， 因 为 repo 
abandon 是 对 git branch-D 命 令 的 封装 。 该 命令 非常 危险 ， 将 直接 删除 分 


文 ， 请 慎 用 。 


用 法 如 下 : 





repo abandon <branchname> [<project>...] 





14. 其 他 命令 

repo grep 

相当 于 对 git grep 的 封装 ， 用 于 在 项 目 文件 中 进行 内 容 碍 找 。 
.tepo smartsync 

相当 于 用 -s 参 数 执行 repo sync。 


* repo forall 


友 代 堪 ， 可 以 对 repo 管 理 的 项 目 进行 迭 代 。 
* fepo manifest 

显示 manifest 文 件 内 容 。 
* repo Vetslon 

显示 repo 的 版 本 号 。 
* repo selfupdate 


用 于 repo 目 身 的 更 新 。 如 果 提 供 --repo-upgraded 参 数 ， 还 会 更 新 各 
个 项 目的 钩子 脚本 。 


25.8 ”repo 命 令 的 工作 流 


图 25-1 是 repo 的 工作 流 ， 每 一 个 代码 贡献 都 起 始 于 repo start 创 建 的 
本 地 工作 分 支 ， 最 终 都 以 repo upload 命 令 将 代码 补丁 发 布 到 代码 审核 服 
务 器 。 


|” 和 


< 

EE DN 

repo upload i git commit 本 wa 
--amend 审核 通过 ? 


--replace 
















repo prune 


图 25-1 tepo 工 作 流 


25.9 ”好 东西 不 能 Android 独 享 





通过 前 面 的 介绍 能 够 体会 到 repo 的 精巧 一 一 repo 巧 妙 地 实现 了 多 Git 
版 本 库 的 管理 。 因 为 repo 使 用 了 清单 版 本 库 ， 所 以 repo 这 一 工具 并 没有 
被 局 限于 Android 项 目 ， 可 以 在 任何 项 目 中 使 用 。 下 面 束 介 绍 三 种 repo 的 
使 用 模式 ， 将 repo 引 入 目 己 的 项 目 〈 非 Android 项 目 ) 中 ， 其 中 第 三 种 
repo 使 用 模式 是 用 我 改造 后 的 repo， 实 现 了 脱离 Gerrit 服 务 器 进行 推送 。 


25.9.1 repo+Gerrit 模 式 


repo 和 Gerrit 是 Android 代 码 管理 的 两 大 文 柱 。 正 如 前 面 在 repo 工 作 
流 中 介绍 的 ， 部 分 的 repo 命 令 从 Git 服 务 器 读 取 ， 这 个 Git 服 务 器 可 以 是 
只 读 的 版 本 库 控 制服 务 器 ， 还 有 部 分 repo 命 令 (repo upload、repo 
download) 访问 的 则 是 代码 审核 服务 左 ， 其 中 repo upload 命 令 还 要 问 代 
码 审核 服务 器 进行 git push 操 作 。 





在 使 用 未 经 改动 的 repo 来 维护 自己 的 项 目 (多 个 版 本 库 组 成 ) 时， 
必须 搭建 Gerrit 代 码 审核 服务 器 。 


搭建 项 目的 版 本 控制 系统 环境 的 一 般 方 法 为 : 


. 用 Git 协 议 或 HTTP 协 议 搭建 Git 服 务 器 。 上 有 具体 搭 建 方法 参见 第 5 


篇 “搭建 Git 服 务 器 ”的 相关 章节 。 


导入 repo.git 工 具 库 。 非 必须 ， 只 是 为 了 减少 不 必要 的 互联 网 操 


Js 
还 可 以 在 内 部 HTTP 服 务 器 维护 一 个 定制 的 repo 引 导 脚 本 ， 非 必 
须 。 


. 建立 Gerrit 代 码 审核 服务 器 。 会 在 第 5 篇 “第 32 章 Getrit 代 码 审 核 服 


a 
务 器 ”中 介绍 Gerrit 的 安装 和 使 用 。 
一 一 创建 相关 的 子 项 目 代 码 库 。 


` 建立 一 个 manifest.git 清 单 库 ， 其 中 remote 元 素 的 fetch 属 性 指向 只 读 
Git 服 务 器 地 址 ，review 属 性 指向 代码 审核 服务 器 地 址 。 示 例如 下 : 





<?xml1 version="1.0" encoding="UTF-8"?> 
<manifest> 
<remote name="example" 
fetch="git://git.example.net/" 
review="review.example.net" /> 
<default revision="master" 
remote="example" /> 





25.9.2 ”repo 无 审核 模式 


Gerrit 代 码 审核 服务 嚣 部署 比 较 麻 烦 ， 更 不 要 说 因为 Gerrit 用 户 界 面 
的 学 习 和 用 户 使 用 习惯 的 更 改 而 带 来 的 困难 了 。 在 一 个 固定 的 团队 内 部 





使 用 repo 可 能 真 的 没有 必要 使 用 Gerrit， 因 为 团队 成 员 都 应 该 熟悉 Git 的 
操作 ， 团 队 成 员 的 编程 能 力 都 可 信 ， 单 元 测试 质量 由 提交 者 保证 ， 集 成 
测试 由 单独 的 测试 团队 进行 ， 即 团队 拥有 一 套 完 整 、 成 型 的 研发 工作 

流 ， 引 入 Gerrit 并 非 必要 。 








脱离 了 Gerrit 服 务 器 ， 直 接 跟 Git 服 务 器 打交道 ，repo 可 以 工作 吗 ? 
是 的 ， 可 以 利用 repo forall 迭 代 器 实现 多 项 目 代 码 的 PUSH， 其 中 有 如 下 





tepo statt 命 令 创 建 本 地 分 支 时 ， 需 要 使 用 和 上 游 同 样 的 分 支 名 。 








如 果 使 用 不 同 的 分 支 名 ， 上 传 时 需要 提供 复杂 的 引用 描述 。 下 面 的 
示例 先 通 过 repo manifest 命 令 确 认 上 游 清单 库 默 认 的 分 文 名 为 master， 再 
使 用 该 分 支 名 (master) 作为 本 地 分 支 名 执行 repo start。 示 例如 下 : 








$ repo manifest -o - | grep default 
<default remote="bj" revision="master"/> 
$ repo start master --all 





推送 不 能 使 用 repo upload， 而 需要 使 用 git push 命 令 。 


可 以 利用 repo forall 迭 代 器 实现 批 命令 方式 执行 。 例 如 





$ repo forall -c git push 





. 如 果 清 单 库 中 的 上 游 git 库 地 址 用 的 是 只 读 地 址 ， 需 要 为 本 地 版 本 


库 一 一 更 改 上 游 版 本 库 地 址 。 


可 以 使 用 foral 迭 代 器 ， 批 量 为 版 本 库 设 置 git push 时 的 版 本 库 地 
址 。 下 面 的 命令 使 用 的 环境 变量 





$ repo forall -c \ 
'git remote set-url --push bj android@bj.ossxp.com:android/${REPO_PROJECT}.git'" 





25.9.3 ”改进 的 repo 无 审核 模式 


前 面 介绍 的 使 用 repo forall 夺 代 霹 实现 在 无 审核 服务 器 情况 下 同上 游 
推送 提交 ， 只 是 权宜 之 计 ， 尤 其 是 用 repo start 建 立 工 作 分 文 要 求 和 上 游 
一 致 ， 实 在 是 有 点 强人 上 所 难 。 


我 改造 了 repo， 增 加 了 两 个 新 的 子 命令 repo config 和 repo push， 让 
repo 可 以 脱离 Gerrit 服 务 器 直接 向 上 游 推 送 。 代 人 码 托管 在 Github 
上 : http://github.com/ossxp-com/repo 。 下 面 简单 地 介绍 一 下 如 何 使 用 改 
造 之 后 的 repo。 


1. 下 载 改 造 后 的 repo 引 导 脚 本 


建议 使 用 改造 后 的 repo 引 导 脚 本 蔡 换 原 脚 本 ， 人 否则 在 执行 repo init 命 
令 时 需要 提供 额外 的 --no-repo-verify 参 数 、 --repo-url 和 --repo-branch 参 
数 。 





$ curl -L -k http://github.com/ossxp-com/repo/raw/master/repo > ~/bin/repo 
$ chmod a+x ~/bin/repo 





2. 用 repo 从 Github 上 检 出 测试 项 目 


如 采 安 装 了 改造 后 的 repo 引 导 脚 本 ， 使 用 下 面 的 命令 初始 化 repo 及 
清单 库 。 





mkdir test 

cd test 

repo init -u git://github.com/ossxp-com/manifest.git 
repo sync 


人 切 份 仇 仇 





如 果 用 的 是 标准 的 (未 经 改造 的 ) repo 引 导 肢 本， 使 用 下 面 的 命 





令 。 
$ mkdir test 
$ cd test 
$ repo init --repo-url=git://github.com/ossxp-com/repo.git \ 
--repo-branch=master --no-repo-verify \ 
-U git://github.com/ossxp-com/manifest.git 
$ repo sync 





当 子 项 目 代码 全 部 同步 完成 后 ， 执 行 make 命 令 。 可 以 看 到 各 个 子 项 
目的 版 本 及 清单 库 的 版 本 。 





$ make 
Version of test1: 1:0.2-dev 
Version of test2: 2:0.2 


Version of manifest: current 





3. 用 repo config 命 令 设置 pushurl 








现在 如 果 进 入 到 各 个 子 项 目 目录 ， 是 无 法 成 功 执行 git push 命 令 的 ， 
因为 上 游 Git 库 的 地 址 是 一 个 只 读 访 问 的 URL， 无 法 提供 写 服务 。 可 以 
用 新 增 的 repo config 命 令 设 置 执行 git push 时 的 URL 地 址 。 





$ repo config repo.pushurl ssh://git@github.com/ossxp-com/ 





设置 成 功 后 ， 可 以 使 用 repo config repo.pushurl 查 看 设置 。 





$ repo config repo.pushurl 
ssh://git@github.com/ossxp-com/ 





4. 创 建 本 地 工作 分 支 


使 用 下 面 的 命令 创建 一 个 工作 分 文 jiangxin。 





$ repo start jiangxin --all 








使 用 repo branches 命 令 可 以 查看 当前 所 有 的 子 项 目 都 属于 jiangxin 分 
Se 





$ repo branches 
* jiangxin | in all projects 





参照 下 面 的 方法 修改 test/test1 子 项 目 。 对 test/test2 项 目 也 作 类 似 修 
改 OD 





$ cd test/test1 
$ echo "1:0.2-jiangxin" > version 


$ git diff 

diff --git a/version b/version 

index 37c65f8..a58ac04 100644 

--- a/version 

+++ b/version 

@@ -1 +1 @@ 

-1:0.2-dev 

+1:0.2-jiangxin 

$ repo status 

# on branch jiangxin 

project test/test1/ branch jiangxin 
-m version 

$ git add -u 

$ git commit -m "0.2-dev -> 0.2-jiangxin" 





执行 make 命 令 ， 看 看 各 个 项 目的 改变 。 





$ make 
Version of test1: 1:0.2-jiangxin 
Version of test2: 2:0.2-jiangxin 


Version of manifest: current 





5.PUSH 到 远程 服务 器 


直接 执行 repo push 就 可 以 推送 各 个 项 目的 改动 。 





$ repo push 





如 果 有 多 个 项 目 同时 进行 了 改动 ， 为 了 避免 出 错 ， 会 弹出 编辑 需 显 
示 因 为 包含 改动 而 需要 推送 的 项 目 列表 。 











Uncomment the branches to upload: 


project test/test1/: 
branch jiangxin ( 1 commit, Mon Oct 25 18:04:51 2010 +0800): 
4f941239 0.2-dev -> 0.2-jiangxin 


project test/test2/: 
branch jiangxin ( 1 commit, Mon Oct 25 18:06:51 2010 +0800): 
86683ece 0.2-dev -> 0.2-jiangxin 


亲 亲 半 半 亲 半 半 和 亲 亲 


二 = 一 3 


每 行 前 面 的 井 吕 都 是 注释 会 被 忽略 。 将 希望 推送 的 分 文 前 的 注释 去 
掉 ， 就 可 以 将 该 项 目的 分 文 执 行 推送 动作 。 下 面 的 操作 中 把 其 中 的 两 个 
分 文 的 注释 都 去 把 了 ， 这 两 个 项 目 当前 分 文 的 改动 会 push 到 上 游 服务 








# Uncomment the branches to upload: 

## 

# project test/test1/: 

branch jiangxin ( 1 commit, Mon Oct 25 18:04:51 2010 +0800 ) : 
# 4f941239 0.2-dev -> 0.2-jiangxin 

# 

# project test/test2/: 

branch jiangxin ( 1 commit, Mon Oct 25 18:06:51 2010 +0800): 
# 86683ece 0.2-dev -> 0.2-jiangxin 





保存 退出 (如 果 使 用 vi 编辑 器 ， 输 入 <ESC>:wqd 执 行 保存 退出 ) 
后 ， 马 上 开始 对 选择 的 各 个 项 目 执 行 git push。 





Counting objects: 5, done. 

Delta compression using up to 2 threads. 

Compressing objects: 100% (2/2), done. 

Writing objects: 100% (3/3), 293 bytes, done. 

Total 3 (delta 0), reused 0 (delta 0) 

To ssh://git@github.com/ossxp-com/test1.git 
27aee23..4f94123 jiangxin -> master 

Counting objects: 5, done. 

Writing objects: 100% (3/3), 261 bytes, done. 

Total 3 (delta 0), reused 0 (delta 0) 

To ssh://git@github.com/ossxp-com/test2.git 
7f0841d. .86683ec jiangxin -> master 

[OK ] test/test1/ jiangxin 

[OK ] test/test2/ jiangxin 





从 推送 的 命令 输出 可 以 看 出 来 ， 本 地 的 工作 分 文 jiangxin 的 改动 被 
推送 到 远程 服务 器 的 master 分 文 〈 本 地 工作 分 文 跟 踪 的 上 游 分 文 ) 上 。 





再 次 执行 repo push， 会 显示 没有 项 目 需要 推送 。 





$ repo push 
no branches ready for upload 





6. 在 远程 服务 器 创建 新 分 文 


如 果 想 在 服务 器 上 创建 一 个 新 的 分 文 ， 访 如何 操作 呢 ? 如 下 使 用 -- 


new_branch 参 数 调 用 repo push 命 令 。 





$ repo start featurel1 --all 
$ repo push --new_branch 





经 过 同样 的 编辑 操作 之 后 自动 调用 git push， 在 服务 硕 上 创建 新 分 文 


featurel 。 





Total 0 (delta 0), reused 0 (delta 0) 

To ssh://git@github.com/ossxp-com/test1.git 
* [new branch] feature1 -> featurel 

Total 0 (delta 0), reused 0 (delta 0) 

To ssh://git@github.com/ossxp-com/test2.git 


* [new branch] featurel -> feature1 
[OK ] test/test1/ featurel1 
[OK ] test/test2/ featurel1 








用 git ls-remote 命 令 得 看 远程 版 本 库 的 分 文 ， 会 发 现 远 程 版 本 库 中 已 
经 建立 了 新 的 分 文 。 





$ git ls-remote git://github.com/ossxp-com/test1.git refs/heads/* 


4f9412399bf8093e880068477203351829a6b1fb refs/heads/featurel 
4f9412399bf8093e880068477203351829a6b1fb refs/heads/master 
b2b246b99ca504f141299ecdbadb23faf6918973 refs/heads/test-0.1 





注意 到 feature1 和 master 分 文 引用 指 岗 了 相同 的 SHA1 哈 希 值 ， 这 是 


为 featurel 分 支 是 直接 从 master 分 支 创 建 的 。 
7. 通 过 不 同 的 清单 库 版 本 ， 切 换 到 不 同 分 支 


换 用 不 同 的 清单 库 ， 需 要 建立 新 的 工作 区 ， 并 且 在 执行 repo init 
时 ， 通 过 -b 参 数 指定 清单 库 的 分 文 。 





$ mkdir test-0.1 

$ cd test-0.1 

$ repo init -u git://github.com/ossxp-com/manifest.git -b test-0.1 
$ repo sync 








当 子 项 目 代码 全 部 同步 完成 后 执行 make 命 令 。 可 以 看 到 各 个 子 项 目 
的 版 本 及 清单 库 的 版 本 不 同 于 之 前 的 输出 。 








$ make 

Version of test1: 1:0.1.4 

Version of test2: 2:0.1.3-dev 
Version of manifest: current-2-g12f9080 








可 以 用 repo manifest 命 令 来 查看 清单 库 。 





$ repo manifest -0 - 
<?xml1 version="1.0" encoding="UTF-8"?> 
<manifest> 
<remote fetch="git://github.com/ossxp-com/" name="github"/> 
<default remote="github" revision="refs/heads/test-0.1"/> 
<project name="test1" path="test/test1"> 
<copyfile dest="Makefile" src="root.mk"/> 
</project> 
<project name="test2" path="test/test2"/> 
</manifest> 





仔细 看 看 上 面 的 清单 文件 ， 可 以 注意 到 默认 的 版 本 指 癌 到 了 


refs/heads/test-0.1 引 用 所 指 问 的 分 支 test-0.1。 


如 果 在 子 项 目 中 修改 、 提 交 ， 人 然后 使 用 repo push 会 将 改动 推送 到 远 
程 版 本 库 的 test-0.1 分 支 中 。 








8. 切 换 到 清单 库 里 程 碑 版 本 


执行 如 下 命令 可 以 查看 清单 库 包 含 的 里 程 碑 版 本 : 





$ git ls-remote --tags git://github.com/ossxp-com/manifest.git 


43e5783a58b46e97270785aa967f09046734c6ab refs/tags/current 
3a6a6da36840e716a14d52252e7b40e6ba6cbdea refs/tags/current^{} 
4735d32613eb50a6c3472cc8087ebf79cc46e0c0 refs/tags/veO.1 
fb1a1b7302a893092ce8b356e83170eee5863f43 refs/tags/voO.1^{} 
b23884d9964660c8dd34b343151aaf968a744400 refs/tags/vO.1.1 
9c4c287069e29d21502472acac34f28896d7b5cc refs/tags/vO.1.1^{} 
127d9789cd4312ed279a7fa683c43eec73d2b28b refs/tags/v0.1.2 
47aaa83866f6d910a118a9a19c2ac3a2a5819b3e refs/tags/voO.1.2^{} 
af3abb7ed0o0a9ef7063e9d814510c527287c92ef6 refs/tags/v0.1.3 
99c69bcfd7e2e7737cc62a7d95f39c6b9ffaf31a refs/tags/voO.1.3^{} 








可 以 从 任意 里 程 碑 版 本 的 清单 库 初始 化 整个 项 目 。 





mkdir vO.1.2 

cd vO.1.2 

repo init -u git://github.com/ossxp-com/manifest.git -b refs/tags/vO.1.2 
repo sync 


切切 仇 仇 








当 子 项 目 代码 全 部 同步 完成 后 执行 make 命 令 。 可 以 看 到 各 个 子 项 目 
的 版 本 及 清单 库 的 版 本 不 同 于 之 前 的 输出 。 








$ make 

Version of test1: 1:0. 
Version of test2: 23 
Version of manifest: vO.1.2 





第 26 章 ”Git 和 SVN 协 同 模型 








在 本 篇 的 最 后 ， 将 会 从 另外 一 个 角度 来 看 版 本 库 协同 。 不 是 不 同 的 
用 户 在 使 用 Git 版 本 库 时 如 何 协同 ， 也 不 是 一 个 项 目 包 含 多 个 Git 版 本 库 
时 如 何 协同 ， 而 是 当 版 本 控制 系统 不 是 Git( 如 Subversion〉 时， 如 何 能 
够 继续 以 Git 的 方式 进行 操作 。 


Subversion 会 在 商业 软件 开发 中 占有 一 席 之 地 ， 因 为 依然 会 有 公司 
需要 严格 而 复杂 的 源 代 码 授 权 。 对 于 熟悉 了 Git 的 用 户 ， 一 定 会 对 
Subversion 的 那 种 一 旦 脱离 网 络 和 服务 器 便 寸 步 难 行 的 工作 模式 厌烦 透 
项。 实际 上 对 Subversion 的 集中 式 版 本 控制 的 不 满 和 改进 在 Git 诞 生 之 前 
就 发 生 了 ， 这 就 是 SVK 1。 


在 2003 年 〈Git 诞 生 的 前 两 年 ) ， 人 台湾 的 高 嘉 良 就 开发 了 SVK， 用 
分 布 式 版 本 控制 的 方法 操作 SVN。 其 设计 思想 非常 朴素 ， 既 然 SVN 的 用 
户 可 以 看 到 有 访问 权限 数据 的 全 部 历史 ， 那 么 也 应 该 能 够 依据 历史 重建 
一 个 本 地 的 SVN 版 本 库 ， 这 样 很 多 SVN 操 作 都 可 以 通过 本 地 的 SVN 进 
行 ， 从 而 脱离 网 络 。 当 对 本 地 版 本 库 的 修改 感到 满意 后 ， 通 过 本 地 SVN 
版 本 和 服务 器 SVN 版 本 库 之 间 的 双向 同步 ， 将 改动 归并 到 服务 器 上 。 这 
种 工作 方式 真 的 非常 酷 。 














不 必 为 SVK 的 文档 缺乏 及 不 再 维护 而 感到 忱 异 ， 因 为 有 更 强 的 工具 


登场 了 ， 这 就 是 git-svn。git-svn 是 Git 软 件 包 的 一 部 分 ， 用 Perl 语 言 开 


发 。 它 的 工作 原理 是 : 
' 将 Subversion 版 本 库 在 本 地 转 挽 为 一 个 Git 库 。 


. 转换 可 以 基于 Subvetsion 的 某 个 目录 ， 或 者 基于 某 个 分 支 ， 或 者 
整个 Subversion 代 码 库 的 所 有 分 支 和 里 程 碑 。 


远程 的 Subvetsion 版 本 库 可 以 和 本 地 的 Git 双 向 同步 。Git 本 地 库 修 
改 推 送 到 远程 Subversion 版 本 库 ， 反 之 亦 然 。 


git-svn 作 为 Git 软 件 包 的 一 部 分 ， 当 Git 从 源码 包 进 行 安装 时 会 默认 
安装 ， 提 供 git svn 命 令 。 而 几乎 所 有 的 Linux 发 行 版 都 将 git-svn 作 为 一 个 
独立 的 软件 单独 发 布 ， 因 此 需要 单独 安装 。 例 如 Debian 和 Ubuntu 运行 下 


面 的 命令 安装 gitrsvn。 





$ sudo aptitude install git-svn 





将 git-svn 独 立 安装 是 因为 git-svn 软 件 包 有 着 特 殊 的 依赖 ， 即 依赖 
Subversion 的 Perl 语 言 绑 定 接口 ，Debian/Ubuntu 上 由 libsvn-perl 软 件 包 提 
供 。 


当 git-svn 正 确 安 装 后 ， 就 可 以 使 用 git svn 命 令 了 。 但 如 果 在 执行 git 
svn--version 时 过 到 下 面 的 错误 ， 则 说 明 Subversion 的 Perl 语 言 绑 定 没有 正 


确 安装 。 





$ git svn --version 

Can't locate loadable object for module SVN::_Core in @INC (@INC contains: 
/usr/share/perl/5.10.1 /etc/perl /usr/local/lib/per1l/5.10.1 
/usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5s 
/usr/lib/perl1/5.10 /usr/share/perl1l/5.10 /usr/local/lib/site perl 
/usr/local/lib/perl1/5.10.0 /usr/local/share/per1l/5.10.0 .) at 
/usr/lib/perl5/SVN/Base.pm line 59 

BEGIN failed--compilation aborted at /usr/lib/perl5/SVN/Core.pm line 5. 
Compilation failed in require at /usr/lib/git-core/git-svn line 41. 





过 到 上 面 的 情况 ， 需 要 检查 本 机 是 否 正确 安装 了 Subversion 及 


Subversion 的 Perl 语 言 绑 定 。 


为 了 便于 对 git-svn 的 介绍 和 演示 ， 要 有 一 个 Subversion 版 本 库 ， 并 
且 要 有 提交 权限 以 便 演示 如 何 用 Git 向 Subversion 进 行 提交 。 下 面 就 在 本 
地 创建 一 个 Subversion 版 本 库 。 





$ svnadmin create /path/to/svn/repos/demo 

$ svn co file:///path/to/svn/repos/demo svndemo 
取出 版 本 0 

$ cd svndemo 

$ mkdir trunk tags branches 

$ svn add * 





A branches 

A tags 

A trunk 

$ svn ci -m "initialized." 
增加 branches 
增加 tags 

增加 trunk 





提交 后 的 版 本 为 1。 





再 同 Subversion 开 发 主线 trunk 中 添加 些 数据 。 





$ echo hello > trunk/README 
$ svn add trunk/README 

A trunk/README 

$ svn ci -m "hello" 


增加 trunk/README 
传输 文件 数据 ， 
提交 后 的 版 本 为 2。 








建立 分 文 : 





$ svn up 

$ svn cp trunk branches/demo-1.0 
A branches/demo-1.0 

$ svn ci -m "new branch: demo-1.0" 
增加 branches/demo-1.0 


提交 后 的 版 本 为 3。 





建立 里 程 碑 : 





$ svn cp -m "new tag: v1.0" trunk file:///path/to/svn/repos/demo/tags/v1.0 
提交 后 的 版 本 为 4。 





[1] http:/ /svk.bestpractical.com/ 


26.1 使 用 git-svn 的 一 般 流程 


使 用 git-svn 的 一 般 流程 参见 图 26-1。 


git add 


git commit 





图 26-1 ”git-svn 工 作 流 


首先 用 git svn clone 命 令 对 Subversion 进 行 克 隆 ， 创 建 一 个 包含 git- 
svn 扩 展 的 本 地 Git 库 。 在 下 面 的 示例 中 ， 使 用 Subversion 的 本 地 协议 
(file://〉 来 访问 之 前 创立 的 Subversion 示 例 版 本 库 ， 实 际 上 git-svn 可 以 
使 用 任何 Subversion 可 用 的 协议 ， 并 可 以 对 远程 版 本 库 进 行 操作 。 








$ git svn clone -s file:///path/to/svn/repos/demo git-svn-demo 
Initialized empty Git repository in /path/to/my/workspace/git-svn-demo/ .git/ 
ri = 2c73d657dfc3aliceca9d465b0b98f9e123b92bb4 (refs/remotes/trunk) 

A README 
r2 = 1863f91b45def159a3ed2c4c4c9428c25213f956 (refs/remotes/trunk) 
Found possible branch point: file:///path/to/svn/repos/demo/trunk => 
file:///path/to/svn/repos/demo/branches/demo-1.0, 2 
Found branch parent: (refs/remotes/demo-1.0) 
1863f91b45def159a3ed2c4c4c9428c25213f956 


Following parent with do_switch 
Successfully followed parent 
r3 = 1adcd5526976fe2a796d932ff92d6c41b7eedcc4 (refs/remotes/demo-1.0) 
Found possible branch point: file:///path/to/svn/repos/demo/trunk => 
file:///path/to/svn/repos/demo/tags/v1.0, 2 
Found branch parent: (refs/remotes/tags/v1.0) 
1863f91b45def159a3ed2c4c4c9428c25213f956 
Following parent with do_switch 
Successfully followed parent 
r4 = ci2aa40c494b495a846e73ab5a3c787calad81e9 (refs/remotes/tags/v1.0) 
Checked out HEAD: 

file:///path/to/svn/repos/demo/trunk r2 





从 上 面 的 输出 可 以 看 出 ， 当 执行 了 git svn clone 之 后 ， 在 本 地 工作 目 
录 创 建 了 一 个 Git 库 (git-svn-demo) ， 并 将 Subversion 的 每 一 个 提交 都 转 
换 为 Git 库 中 的 提交 。 进 入 git-svn-demo 目 录 ， 看 看 用 git-svn 克 隆 出 来 的 
版 本 库 。 





cd git-svn-demo/ 
git branch -a 
master 
remotes/demo-1.0 
remotes/tags/v1.0 
remotes/trunk 
$ git 1og 
commit 1863f91b45def159a3ed2c4c4c9428c25213f956 
Author: jiangxin <jiangxin@f79726c4-f016-41bd-acd5-6c9acb7664b2> 
Date: Mon Nov 1 05:49:41 2010 +0000 
hello 
git-svn-id: file:///path/to/svn/repos/demo/trunk@2 
f79726c4-f016-41bd-acd5-6c9acb7664b2 
commit 2c73d657dfc3a1lceca9d465b0b98f9e123b92bb4 
Author: jiangxin <jiangxin@f79726c4-f016-41bd-acd5-6c9acb7664b2> 
Date: Mon Nov 1 05:47:03 2010 +0000 
initialized. 
git-svn-id: file:///path/to/svn/repos/demo/trunk@1 
f79726c4-f016-41bd-acd5-6c9acb7664b2 


+ 奶 切 





看 到 Subversion 版 本 库 的 分 支 和 里 程 碑 都 被 克隆 出 来 ， 并 保存 在 
refs/remotes 下 的 引用 中 。 在 git log 的 输出 中 ， 可 以 看 到 Subversion 的 提交 
的 确 被 转换 为 Git 的 提交 。 





下 面 就 可 以 在 Git 库 中 进行 修改 ， 并 在 本 地 提交 《用 git commit 命 


令 ) 。 





$ cat README 


hello 
$ echo "I am fine." >> README 
$ git add -u 


$ git commit -m "my hack 1." 
[master 55e5fd7] my hack 1. 
1 files changed， 1 insertions(+), 0 deletions(-) 
$ echo "Thank you." >> README 
$ git add -u 
$ git commit -m "my hack 2." 
[master fie00b5] my hack 2. 
1 files changed, 1 insertions(+), 0 deletions(-) 





对 工作 区 中 的 README 文 件 修改 了 两 次 ， 并 进行 了 本 地 的 提交 。 
查看 这 时 的 提交 日 志 ， 会 太 现 最 新 的 两 个 提交 和 之 前 的 历次 提交 略 有 不 
同 ， 最 新 的 两 个 提交 的 提交 说 明 中 不 包含 git-svn-id: 标记 。 








$ git 1og 
commit fle00b52209f6522dd8135d27e86370de552a7b6 
Author: Jiang Xin <jiangxin@ossxp.com> 
Date: Thu Nov 4 15:05:47 2010 +0800 

my hack 2， 
commit 55e5fd794e6208703aa999004ec2e422b3673ade 
Author: Jiang Xin <jiangxin@ossxp.com> 
Date: Thu Nov 4 15:05:32 2010 +0800 

my hack 1. 
commit 1863f91b45def159a3ed2c4c4c9428c25213f956 
Author: jiangxin <jiangxin@f79726c4-f016-41bd-acd5-6c9acb7664b2> 
Date: Mon Nov 1 05:49:41 2010 +0000 

hello 

git-svn-id: file:///path/to/svn/repos/demo/trunk@2 
f79726c4-f016-41bd-acd5-6c9acb7664b2 
commit 2c73d657dfc3alceca9d465b0b98f9e123b92bb4 
Author: jiangxin <jiangxin@f79726c4-f016-41bd-acd5-6c9acb7664b2> 
Date: Mon Nov 1 05:47:03 2010 +0000 

initialized. 

git-svn-id: file:///path/to/svn/repos/demo/trunk@1 
f79726c4-f016-41bd-acd5-6c9acb7664b2 





现在 就 可 以 同 Subversion 服 务 器 推送 改动 了 。 但 在 真实 的 环境 中 ， 


往往 在 同 服务 器 推送 时 ， 己 经 有 其 他 用 户 在 服务 器 上 进行 了 提交 ， 而 且 
更 糟 的 是 ， 先 于 我 们 的 提交 会 造成 我 们 的 提交 冲突 ! 现在 就 人 为 地 制造 
一 个 冲突 ， 使 用 svn 命 令 在 Subversion 版 本 库 中 执行 一 次 提交 。 








$ svn checkout file:///path/to/svn/repos/demo/trunk demo 
A demo/README 

取出 版 本 4。 

$ cd demo/ 

$ cat README 

hello 

$ echo "HELLO." > README 

$ svn commit -m "hello -> HELLO." 
正在 发 送 README 

传输 文件 数据 ， 

提交 后 的 版 本 为 5。 














好 的 ， 已 经 模拟 了 一 个 用 户 先 于 我 们 更 改 了 Subversion 版 本 库 。 现 
在 回 到 用 git-svn 克 隆 的 本 地 版 本 库 ， 执 行 git svn dcommit 操 作 ， 将 Git 中 
的 提交 推送 到 Subversion 版 本 库 中 。 





$ git svn dcommit 
Committing to file:///path/to/svn/repos/demo/trunk ... 
事务 过 时 : 文件 "/trunk/README" 已 经 过 时 at /usr/1lib/git-core/git-svn line 572 








显然 ， 由 于 Subversion 版 本 库 中 包含 了 新 的 提交 ， 导 致 执行 git svn 
dcommit 出 错 。 这 时 须 执 行 git svn fetch 命 令 ， 以 从 Subversion 版 本 库 获 取 
更 新 。 





$ git svn fetch 
M README 
r5 = fae6dab863ed2152f71bcb2348d476d47194fdd4 (refs/remotes/trunk) 
$ git status 
# On branch master 
nothing to commit (working directory clean) 


COCO 全 于 | 


当 获 取 了 新 的 Subversion 提 交 之 后 ， 需 要 执行 git svn rebase 将 Git 中 
未 推送 到 Subversion 的 提交 通过 变 基 操作 转化 为 继 Subversion 最 新 提交 的 
线性 提交 。 这 是 因为 Subversion 的 提交 都 是 线性 的 。 





$ git svn rebase 

First, rewinding head to replay your work on top of it... 

Applying: my hack 1. 

Using index info to reconstruct a base tree... 

Falling back to patching base and 3-way merge... 

Auto-merging README 

CONFLICT (content): Merge conflict in README 

Failed to merge in the changes. 

Patch failed at 0001 my hack 1. 

When you have resolved this problem run "git rebase --continue". 

If you would prefer to Skip this patch, instead run "git rebase --skip". 
To restore the original branch and stop rebasing run "git rebase --abort". 
rebase refs/remotes/trunk: command returned error: 1 





果不其然 ， 变 基 时 发 生 了 冲突 ， 这 是 因为 Subversion 中 他 人 的 修改 
和 我 们 在 Git 库 中 的 修改 都 改动 了 同一 个 文件 ， 并 且 改 动 了 相近 的 行 。 
下 面 按照 git rebase 冲 突 解决 的 标准 步 又 进行 ， 直 到 成 功 完成 变 基 操作 ， 
具体 操作 步骤 如 下 。 








(1) 先 编辑 README 文 件 以 解决 冲突 。 





$ git status 
# Not currently on any branch. 
# Unmerged paths: 


# (use "git reset HEAD <file>..." to unstage) 

# (use "git add/rm <file>..." as appropriate to mark resolution) 
# 

# both modified: README 

## 


no _ changes added to commit (use "git add" and/or "git commit -a") 
$ vi README 





(2) 处 于 冲突 状态 的 REAEME 文 件 的 内 容 。 


一 


<<<<<<< HEAD 
HELLO. 


hello 
I am fine. 
>>>>>>> my hack 1. 





(3) 下面 是 修改 后 的 内 容 ， 保 存 退出 。 





HELLO. 
I am fine. 





(4) 执行 git add 命 令 解决 冲突 。 





$ git add README 





(5) 调用 git rebase--continue 完 成 变 其 操作 。 





$ git rebase --continue 

Applying: my hack 1. 

Applying: my hack 2. 

Using index info to reconstruct a base tree... 
Falling back to patching base and 3-way merge... 
Auto-merging README 








(6) 看 看 变 基 之 后 的 Git 版 本 库 日 志 : 





$ git 1og 
commit e382f2e99eca07bc3a92ece89f80a7a5457acfd8 
Author: Jiang Xin <jiangxin@ossxp.com> 
Date: Thu Nov 4 15:05:47 2010 +0800 

my hack 2， 
commit 6e7egc7dccf5a072404a28f06cegc83d77988bgob 
Author: Jiang Xin <jiangxin@ossxp.com> 
Date: Thu Nov 4 15:05:32 2010 +0800 

my hack 1. 
commit fae6dab863ed2152f71bcb2348d476d47194fdd4 
Author: jiangxin <jiangxin@f79726c4-f016-41bd-acd5-6c9acb7664b2> 
Date: Thu Nov 4 07:15:58 2010 +0000 

hello -> HELLO. 


git-svn-id: file:///path/to/svn/repos/demo/trunk@s5 
f79726c4-f016-41bd-acd5-6c9acb7664b2 
commit 1863f91b45def159a3ed2c4c4c9428c25213f956 
Author: jiangxin <jiangxin@f79726c4-f016-41bd-acd5-6c9acb7664b2> 
Date: Mon Nov 1 05:49:41 2010 +0000 

hello 

git-svn-id: file:///path/to/svn/repos/demo/trunk@2 
f79726c4-f016-41bd-acd5-6c9acb7664b2 
commit 2c73d657dfc3alceca9d465b0b98f9e123b92bb4 
Author: jiangxin <jiangxin@f79726c4-f016-41bd-acd5-6c9acb7664b2> 
Date: Mon Nov 1 05:47:03 2010 +0000 

initialized. 

git-svn-id: file:///path/to/svn/repos/demo/trunk@1 
f79726c4-f016-41bd-acd5-6c9acb7664b2 





(7) 当 变 基 操 作成 功 完成 后 ， 再 执行 git svn dcommit|5jSubversion 
推送 Git 库 中 的 两 个 新 提交 。 





$ git svn dcommit 
Committing to file:///path/to/svn/repos/demo/trunk ... 


M README 
Committed r6 
M README 


r6 = doeb86bdfad4720e0a24edc49ec2b52e50473e83 (refs/remotes/trunk) 
No changes between current HEAD and refs/remotes/trunk 

Resetting to the latest refs/remotes/trunk 

Unstaged changes after reset: 


M README 

M README 
Committed r7 

M README 


r7 = 69f4aa56eb96230aedd7c643f65d03b618ccc9e5 (refs/remotes/trunk) 
No changes between current HEAD and refs/remotes/trunk 
Resetting to the latest refs/remotes/trunk 





(8) 推送 之 后 本 地 Git 库 中 最 新 的 两 个 提交 的 提交 说 明 中 也 授 入 了 


git-svn-id: 标 签 。 这 个 标签 的 作用 非常 重要 ， 在 下 一 节 会 予以 介绍 。 





$ git lo0g -2 
commit 69f4aa56eb96230aedd7c643f65d03b618ccc9e5 
Author: jiangxin <jiangxin@f79726c4-f016-41bd-acd5-6c9acb7664b2> 
Date: Thu Nov 4 07:56:38 2010 +0000 

my hack 2， 

git-svn-id: file:///path/to/svn/repos/demo/trunk@7 
f79726c4-f016-41bd-acd5-6c9acb7664b2 
commit doeb86bdfad4720e0a24edc49ec2b52e50473e83 
Author: jiangxin <jiangxin@f79726c4-f016-41bd-acd5-6c9acb7664b2> 
Date: Thu Nov 4 07:56:37 2010 +0000 


my hack 1. 
git-svn-id: file:///path/to/svn/repos/demo/trunk@6 
f79726c4-f016-41bd-acd5-6c9acb7664b2 


ee | 


26.2 ”git-svn 的 奥秘 


通过 上 面 对 git-svn 的 工作 流程 的 介绍 ， 相 信和 您 已 经 能 够 体会 到 git- 
svn 的 强大 。 那 么 git-svn 是 怎么 做 到 的 呢 ? 


git-svn 只 是 在 本 地 Git 库 中 增加 了 一 些 附 加 的 设置 和 特殊 的 引用 ， 并 
引入 了 附加 的 可 重建 的 数据 库 实现 对 Subversion 版 本 库 的 跟踪 。 


26.2.1 Git 库 配 置 文件 的 扩展 及 分 支 映射 





当 执 行 git svn init 或 git svn clone 时 ，git-svn 会 通过 在 Git 库 的 配置 文 
件 中 增加 一 个 小 节 ， 记 录 Subversion 版 本 库 的 URL， 以 及 Subversion 分 
文 /里 程 碑 和 本 地 Git 库 的 引用 之 间 的 对 应 关系 。 


例如 : 当 执 行 git svn clone-sfile:///path/to/svn/repos/demo 指令 时 ， 会 
在 创建 的 本 地 Git 库 的 配置 文件 .git/config 中 引入 下 面 的 新 配置 : 





[svn-remote "svn"] 
url = file:///path/to/svn/repos/demo 
fetch = trunk:refs/remotes/trunk 
branches = branches/*:refs/remotes/* 
tags = tags/*:refs/remotes/tags/* 





默认 svn-remote 的 名 字 为 swn， 上 所 以 新 增 的 配置 小 节 的 名 字 为 : [svn- 
remote"svn"]。 在 git-svn 克 隆 时 ， 可 以 使 用 --remote 参 数 设 置 不 同 的 svn- 


remote 名 称 ， 但 是 并 不 建议 使 用 。 因 为 一 旦 使 用 --remote 参 数 更 改 svn- 
remote 名 称 ， 必 须 在 gitrsvn 的 其 他 命令 中 都 使 用 --remote 参 数 ， 人 否则 报告 


[svn-remote"svn"] 配 置 小 节 未 找到 。 
该 小 节 中 主要 的 配置 有 : 
-url=<URL> 
设置 Subversion 版 本 库 的 地 址 。 
. fetch=<svn-path>:<git-refspec> 
Subversion 的 开发 主线 和 Git 版 本 库 引 用 的 对 应 关系 。 


在 上 例 中 Subversion 的 trunk 目 录 对 应 于 Git 的 refsremotes/trunk 引 


* branches=<svn-path>:<git-refspec> 


Subversion 的 开发 分 支 和 和 Git 版 本 库 引 用 的 对 应 关系 。 可 以 包含 多 条 
branches 的 设置 ， 以 便 将 分 散在 不 同 目录 下 的 分 支 汇 总 。 


在 上 例 中 Subversion 的 branches 子 目录 的 下 一 级 子 目 录 
(branches/x*) 所 代表 的 分 支 在 Git 的 refs/remotes/ 下 建 六 引用 。 


* tags=<svn-path>:<git-refspec> 


Subversion 的 里 程 碑 和 Git 版 本 库 引 用 的 对 应 关系 ， 可 以 包含 多 条 
tags 的 设置 ， 以 便 将 分 散在 不 同 目录 下 的 里 程 碑 汇总 。 


在 上 例 中 Subversion 的 tags 子 目录 的 下 一 级 子 目 录 (tags/*) 所 代表 
的 里 程 碑 在 Git 的 refs/remotes/tags 下 建立 引用 。 


可 以 看 到 Subversion 的 主线 和 分 支 默 认 都 直接 被 映射 到 refs/remotes/ 
下 。 如 trunk 主 线 对 应 于 refs/remotes/trunk， 分 支 demo-1.0 对 应 于 
refs/remotes/demo-1.0。Subversion 的 里 程 碑 因 为 有 可 能 和 分 支 同 名 ， 
此 被 映射 到 refs/remotes/tags/ 之 下 ， 这 样 里 程 碑 和 分 支 的 映射 束 放 到 了 不 
同 的 目录 下 ， 不 会 互相 影响 。 





26.2.2 ”Git 工 作 分 支 和 Subversion 如 何 对 应 


Git 默 认 的 工作 分 文 是 master， 而 看 到 上 例 中 的 Subversion 主 线 在 Git 
中 对 应 的 远程 分 支 为 refs/remotes/trunk。 那 么 在 执行 git svn rebase 时 ， 
git-svn 是 如 何 知道 当前 的 HEAD 对 应 的 分 文 是 基于 哪个 Subversion 跟 踪 分 
支 进行 的 变 基 呢 ? 还 有 就 是 执行 git svn dcommit 时 ， 当 前 的 工作 分 支 应 
该 将 改动 推送 到 哪个 Subversion 分 支 中 去 呢 ? 


很 自然 地 会 按照 Git 的 方式 进行 思考 ， 期 望 在 .gityconfig 配 置 文件 中 
找到 类 似 [branch master] 之 类 的 配置 小 节 。 实 际 上 ， 在 git-svn 的 Git 库 的 
配置 文件 中 可 能 根本 就 不 存在 [branch.…] 小 节 。 那 么 gitrsvn 是 如 何 确定 当 





前 Git 工 作 分 支 和 远程 Subversion 版 本 库 的 分 支 建立 了 对 应 呢 ? 


其 实 奥秘 就 在 Git 的 日 志 中 。 当 在 工作 区 执行 gitlog 时 ， 会 看 到 包含 
git-svn-id: 标 识 的 特殊 日 志 。 发 现 的 最 近 的 一 个 git-svn-id: 标 识 会 确定 当 


前 分 支 提交 的 Subversion 分 支 。 


下 面 继续 上 一 节 的 示例 ， 先 切换 到 分 支 ， 并 将 提交 推送 到 
Subversion 的 分 支 demo-1.0 中 ， 有 具体 操作 过 程 如 下 。 





(1) 首先 在 Git 库 中 会 看 到 有 一 个 对 应 于 Subversion 分 支 的 远程 分 
支 和 一 个 对 应 于 Subversion 里 程 碑 的 远程 引用 。 





$ git branch -r 
demo-1.0 
tags/v1.0 
trunk 





(2) 然后 基于 远程 分 文 demo-1.0 建 立 本 地 工作 分 文 myhack。 





$ git checkout -b myhack refs/remotes/demo-1.0 
Switched to a new branch 'myhack' 
$ git branch 
master 
* myhack 





(3) 在 myhack 分 文 做 一 些 改动 并 提交 。 





$ echo "Git" >> README 
$ git add -u 
$ git commit -m "say hello to Git." 
[myhack d391fd7] say hello to Git. 
1 files changed, 1 insertions(+), 0 deletions(-) 





(4) 下 面 看 看 Git 的 提交 日 志 。 





$ git 1og --first-parent 
commit d391fd75c33f62307c3add1498987fa3eb70238e 
Author: Jiang Xin <jiangxin@ossxp.com> 
Date: Fri Nov 5 09:40:21 2010 +0800 

Say hello to Git ， 
commit 1iadcd5526976fe2a796d932ff92d6c41b7eedcc4 
Author: jiangxin <jiangxin@f79726c4-f016-41bd-acd5-6c9acb7664b2> 
Date: Mon Nov 1 05:54:19 2010 +0000 

new branch: demo-1.0 

git-svn-id: file:///path/to/svn/repos/demo/branches/demo-1.0@3 
f79726c4-f016-41bd-acd5-6c9acb7664b2 
commit 1863f91b45def159a3ed2c4c4c9428c25213f956 
Author: jiangxin <jiangxin@f79726c4-f016-41bd-acd5-6c9acb7664b2> 
Date: Mon Nov 1 05:49:41 2010 +0000 

hello 

git-svn-id: file:///path/to/svn/repos/demo/trunk@2 
f79726c4-f016-41bd-acd5-6c9acb7664b2 
commit 2c73d657dfc3alceca9d465b0b98f9e123b92bb4 
Author: jiangxin <jiangxin@f79726c4-f016-41bd-acd5-6c9acb7664b2> 
Date: Mon Nov 1 05:47:03 2010 +0000 

initialized. 

git-svn-id: file:///path/to/svn/repos/demo/trunk@1 
f79726c4-f016-41bd-acd5-6c9acb7664b2 





(5) 看 到 了 上 述 Git 日 志 中 出 现 的 第 一 个 git-svn-id: 标 识 的 内 容 为 : 





git-svn-id: file:///path/to/svn/repos/demo/branches/demo-1.0@3 
f79726c4-f016-41bd-acd5-6c9acb7664b2 





是 说 ， 当 需要 将 Git 提 交 推 送 给 Subversion 服 务 器 时 ， 需 要 推送 
到 地 址 : file:///path/to/svn/repos/demo/branches/demo-1.0 。 


(6) 执行 git svn dcommit， 果 然 是 推送 到 Subversion 的 demo-1.0 分 
Se 





$ git svn dcommit 

Committing to file:///path/to/svn/repos/demo/branches/demo-1.0 ... 
M README 

Committed r8 
M README 


r8 = a8b32d1b533d308bef59101c1f2c9a16baf91e48 (refs/remotes/demo-1.0) 
No changes between current HEAD and refs/remotes/demo-1.0 
Resetting to the latest refs/remotes/demo-1.0 





26.2.3 ”其 他 辅助 文件 





在 Git 版 本 库 中 ，git-svn 在 .git/svn 目 录 下 保存 了 一 些 索 引文 件 ， 便 于 
git-svn 更 加 快速 地 执行 。 


.git/svn/.metadata 文 件 是 类 似 于 .git/config 文 件 一 样 的 INI 文 件 ， 其 中 
保存 了 版 本 库 的 URL、 版 本 库 UUID、 分 支 和 里 程 碑 的 最 后 获取 的 版 本 


号 
号 等 。 





; This file is used internally by git-svn 

; You should not have to edit it 

[svn-remote "svn"] 
reposRoot = file:///path/to/svn/repos/demo 
uuid = f79726c4-f016-41bd-acd5-6c9acb7664b2 
branches-maxRev = 8 
tags-maxRev = 8 





在 .git/svn/refs/remotes 目 录 下 ， 以 各 个 分 文 和 里 程 碑 为 名 的 各 个 子 目 
录 下 都 包含 了 一 个 名 为 .rev_map.<SVN-UUID> 的 索引 文件 ， 这 个 文件 用 
于 记录 Subversion 的 提交 ID 和 Git 的 提交 ID 的 映射 。 


目录 .git/svn 的 辅助 文件 由 git-svn 维 护 ， 不 要 手工 修改 否则 会 造成 git- 
svn 不 能 正常 工作 。 


26.3 多样 的 git-svn 元 隆 模 式 





在 前 面 的 git-svn 示 例 中 ， 使 用 git svn clone 命 令 完 成 对 远程 版 本 库 的 
克隆 ， 实 际 上 git svn clone 相 当 于 两 条 命令 ， 即 : 





git svn clone = git svn init + git svn fetch 





命令 git svn init 只 完成 两 个 工作 。 一 是 在 本 地 建立 一 个 空 的 Git 版 本 
库 ， 另 外 是 修改 .gitconfig 文 件 ， 在 其 中 建立 Subversion 和 Git 之 间 的 分 文 
映射 关系 。 在 实际 使 用 中 ， 我 更 喜欢 使 用 git svn init 命 令 ， 因 为 这 样 可 
以 对 Subversion 和 Git 的 分 文 映 射 进 行 手 工 修 改 。 该 命令 的 用 法 是 : 




















用 法 : git svn init [options] <subversion-url> [local-dir] 
[ 选 的 主要 参数 有 : 
--Stdlayout， -s 





可 省 





--trunk, -T <arg> 
--branches, --b=s@ 
--tags, --t=s@ 


--config-dir <arg> 
--ignore-paths <arg> 
--prefix <arg> 
--USername <arg> 





其 中 --username 参 数 用 于 设 定 远程 Subversion 服 务 器 认证 时 提供 的 用 
户 名 。 参 数 --prefix 用 于 设置 在 Git 的 refs/remotes 下 保存 引用 时 使 用 的 前 
级 。 参 数 --ignore-paths 后 面 跟 一 个 正则 表达 式 定义 忽略 的 文件 列表 ， 这 
些 文件 将 不 巴克 隆 。 


最 第 用 的 参数 是 -s。 该 参数 和 前 面 演 示 的 git clone 命 令 中 的 一 样 ， 即 
使 用 标准 的 分 支 / 里 程 碑 部 车 方式 克隆 Subversion 版 本 库 。Subversion 约 
定 俗 成 使 用 rrunk 目 录 跟 踪 主 线 的 开 及 ， 使 用 branches 目 录 保 存 各 个 分 
支 ， 使 用 tags 目 录 来 记录 里 程 碑 。 





即 命令 : 





$ git svn init -s file:///path/to/svn/repos/demo 








$ git svn init -T trunk -b branches -t tags file:///path/to/svn/repos/demo 








有 的 Subversion 版 本 库 的 分 支 可 能 分 散 于 不 同 的 目录 下 ， 例 如 有 的 
位 于 branches 目 录 ， 有 的 位 于 sandbox 目 录 ， 可 以 使 用 下 面 的 命令 : 





$ git svn init -T trunk -b branches -b sandbox -t tags 
file:///path/to/svn/repos/demo git-svn-test 
Initialized empty Git repository in /path/to/my/workspace/git-svn-test/.git/ 





查看 本 地 克隆 版 本 库 的 配置 文件 : 





$ cat git-svn-test/.git/config 
[core] 
repositoryformatversion = 0 
filemode = true 
bare = false 
logallrefupdates = true 
[svn-remote "svn"] 
url = file:///path/to/svn/repos/demo 
fetch = trunk:refs/remotes/trunk 
branches = branches/*:refs/remotes/* 
branches = sandbox/*:refs/remotes/* 


tags = tags/*:refs/remotes/tags/* 





可 以 看 到 在 [svn-remote"svn"] 小 市 中 包含 了 两 条 branches 配 置 ， 这 就 
会 实现 将 Subversion 分 散 于 不 同 目 录 的 分 文 都 克隆 出 来 。 如 果 担 心 
Subversion 的 branches 目 录 和 sandbox 目 录 下 出 现 同名 的 分 支 ， 从 而 导致 
在 Git 库 的 refs/remotes/ 下 造成 履 盖 ， 可 以 在 版 本 库 尚 未 执行 git svn fetch 
之 前 编辑 .giVyconfig 文 件 ， 避 免 可 能 出 现 的 牙 盖 。 例 如 编辑 后 的 [svn- 


remote"svn"] 配 置 小 节 : 











[svn-remote "svn"] 
url = file:///path/to/svn/repos/demo 
fetch = trunk:refs/remotes/trunk 
branches = branches/*:refs/remotes/branches/* 
branches = sandbox/*:refs/remotes/sandbox/* 
tags = tags/*:refs/remotes/tags/* 





如 果 项 目的 分 支 或 里 程 碑 非常 多 ， 也 可 以 修改 [svn-remote"svn"] 配 
置 小 节 中 的 版 本 号 通配符 ， 使 得 只 获取 部 分 分 支 或 里 程 碑 。 例 如 下 面 的 
配置 小 节 : 





[svn-remote "svn"] 
url = http://server.org/svn 
fetch = trunk/src:refs/remotes/trunk 
branches = branches/{red, green}/src:refs/remotes/branches/* 
tags = tags/{1.0, 2.0}/src:refs/remotes/tags/* 








如 果 只 关心 Subversion 的 某 个 分 文 甚至 某 个 子 目 录 ， 而 不 关心 其 他 
分 文 或 目录 ， 那 就 更 简单 了 ， 不 带 参 数 地 执行 git svn init 针 对 Subversion 
的 某 个 具体 路 径 执行 初始 化 就 可 以 了 。 








$ git svn init file:///path/to/svn/repos/demo/trunk 








有 的 情况 下 ， 版 本 库 太 大 ， 而 且 对 历史 不 感 兴趣 ， 可 以 只 元 隆 最 近 
的 部 分 提交 。 这 时 可 以 通过 git svn fetch 命 令 的 -r 参 数 实现 部 分 提交 的 克 


隆 。 





$ git svn init file:///path/to/svn/repos/demo/trunk git-svn-test 

Initialized empty Git repository in /path/to/my/workspace/git-svn-test/.git/ 
$ cd git-svn-test 

$ git svn fetch -r 6:HEAD 


A README 
r6 = 053b641b7edd2f1a59a007f27862d98fe5bcda57 (refs/remotes/git-svn) 
M README 


r7 = 75c17ea61d8527334855a51e65ac98c981f545d7 (refs/remotes/git-svn) 
Checked out HEAD: 


file:///path/to/svn/repos/demo/trunk r7 





当然 也 可 以 使 用 git svn clone 命 令 实现 部 分 克隆 : 





$ git svn clone -r 6:HEAD \ 
file:///path/to/svn/repos/demo/trunk git-svn-test 
Initialized empty Git repository in /path/to/my/workspace/git-svn-test/.git/ 


A README 
r6 = 053b641b7edd2f1a59a007f27862d98fe5bcda57 (refs/remotes/git-svn) 
M README 


r7 = 75c17ea61d8527334855a51e65ac98c981f545d7 (refs/remotes/git-svn) 
Checked out HEAD : 


file:///path/to/svn/repos/demo/trunk r7 


Kee = 一 一 


26.4 ”共享 git-svn 的 克隆 库 








当 一 个 Subversion 版 本 库 非 党 庞大 而 且 还 不 在 同一 个 局 域 网 内 ， 执 
行 git svn clone 可 能 需要 花费 很 多 时 间 。 为 了 避免 因 重 复 执行 git svn 
clone 而 导致 时 间 上 的 浪费 ， 可 以 将 一 个 已 经 使 用 git-svn 克 隆 出 来 的 Git 
库 共 诗 ， 其 他 人 基于 此 Git 进 行 殉 隆 ， 然 后 再 用 特殊 的 方法 重建 和 
Subversion 的 关联 。 还 记得 之 前 提 到 过 .givVsvn 目 录 下 的 辅助 文件 可 以 重 
建 吗 ? 





例如 通过 工作 区 中 己 经 存在 的 git-svn-demo 执 行 元 隆 。 





$ git clone git-svn-demo myclone 
Initialized empty Git repository in /path/to/my/workspace/myclone/ .git/ 





进入 新 的 克隆 中 ， 会 发 现 新 的 元 隆 缺 乏 跟 中 Subversion 分 支 的 引 


用 ， 即 refsAremotes/trunk 等 。 





$ cd myclone/ 

$ git branch -a 

* master 
remotes/origin/HEAD -> origin/master 
remotes/origin/master 
remotes/origin/myhack 





这 是 因为 Git 元 隆 默 认 不 复制 远程 版 本 库 的 refs/remotes/ 下 的 引用 。 
可 以 用 git fetch 命 令 获 取 refs/remotes 的 引用 。 





$ git fetch origin refs/remotes/*:refs/remotes/* 
From /path/to/my/workspace/git-svn-demo 


* [new branch] demo-1.0 -> demo-1.0 
* [new branch] tags/v1.0 -> tags/vi.0 
* [new branch] trunk -> trunk 








现在 这 个 从 git-svn 库 中 克隆 出 来 的 版 本 库 已 经 有 了 相同 的 
Subversion 跟 踪 分 文 ， 但 是 .git/config 文 件 还 缺乏 相应 的 [svn-remote"svn"] 
配置 。 可 以 通过 使 用 同样 的 git svn init 命 令 实现 。 








$ pwd 

/path/to/my/workspace/myclone 

$ git svn init -s file:///path/to/svn/repos/demo 
$ git config --get-regexp 'svn-remote.*' 
svn-remote.svn.url file:///path/to/svn/repos/demo 
svn-remote.svn.fetch trunk:refs/remotes/trunk 
svn-remote.svn.branches branches/*:refs/remotes/* 
svn-remote.svn.tags tags/*:refs/remotes/tags/* 





但 是 元 隆 版 本 库 相 比 用 git-svn 元 隆 的 版 本 库 还 缺乏 .git/svn 下 的 辅助 
文件 。 实 际 上 可 以 用 git svn rebase 命 令 重 建 ， 同 时 这 条 命令 也 可 以 变 基 
到 Subversion 相 应 分 文 的 最 新 提交 上 。 





$ git svn rebase 
Rebuilding .git/svn/refs/remotes/trunk/.rev_map.f79726c4-f016-41bd-acd5-6c9ac 
b7664b2 ... 
ri = 2c73d657dfc3alceca9d465b0b98f9e123b92bb4 
= 1863f91b45def159a3ed2c4c4c9428c25213f956 
r5 = fae6dab863ed2152f71bcb2348d476d47194fdd4 
= doeb86bdfad4720e0a24edc49ec2b52e50473e83 
r7 = 69f4aa56eb96230aedd7c643f65d03b618ccc9e5 


rebuilding .git/svn/refs/remotes/trunk/.rev_map.f79726c4-f016-41bd-acd5-6c9ac 
b7664b2 
Current branch master is up to date. 





如 果 执 行 git svn fetch 则 会 对 所 有 的 分 支 都 进行 重建 。 





$ git svn fetch 


Rebuilding .git/svn/refs/remotes/demo-1.0/.rev_map.f79726c4-f016-41bd-acd5-6c 
9acb7664b2 ...， 

r3 = 1adcd5526976fe2a796d932ff92d6c41b7eedcc4 

r8 = a8b32d1b533d308bef59101c1f2c9a16baf91e48 

Done 

rebuilding .git/svn/refs/remotes/demo-1.0/.rev_ map.f79726c4-f016-41bd-acd5-6c 
9acb7664b2 

Rebuilding .git/svn/refs/remotes/tags/v1.0/.rev_map.f79726c4-f016-41bd-acd5-6c 
9acb7664b2 ... 

r4 = ci2aa40c494b495a846e73ab5a3c787calad81e9 

Done 

rebuilding .git/svn/refs/remotes/tags/v1.0/.rev map.f79726c4-f016-41bd-acd5-6 
c9acb7664b2 








至 此 ， 从 git-svn 克 隆 库 二 次 元 隆 的 Git 库 ， 己 经 和 原生 的 git-svn 库 一 
样 使 用 git-svn 命 令 了 了。 


26.5 ”git-svn 的 局 限 


Subversion 和 Git 的 分 支 实现 有 着 巨大 的 不 同 。Subversion 的 分 文 和 
里 程 碑 ， 是 用 轻 量 级 拷贝 实现 的 ， 虽 然 创 建 分 支 和 里 程 碑 的 速度 也 很 
快 ， 但 是 很 难 维护 。 即 使 Subversion 在 1.5 之 后 引入 了 svn:mergeinfo 属 性 
对 合并 过 程 进行 标记 ， 但 是 也 不 可 能 让 Subversion 的 分 支 逻 辑 更 清晰 。 
git-svn 无 须 利 用 svn:mergeinfo 属 性 也 可 实现 对 Subversion 合 并 的 追踪 ， 在 
合并 的 时 候 也 不 会 对 svn:mergeinfo 属 性 进行 更 改 ， 因 此 在 使 用 git-svn 操 
作 时 ， 如 果 在 不 同 分 支 间 进行 合并 ， 会 导致 Subversion 的 svn:mergeinfo 
属性 没有 相应 的 更 新 ， 从 而 导致 Subversion 用 户 进 行 合并 时 因为 重复 合 
并 而 冲突 。 











简 而 言 之 ， 在 使 用 gitrsvn 时 尽量 不 要 在 不 同 的 分 文 之 间 进 行 合并 ， 
而 是 尽量 在 一 个 分 文 下 进行 线性 的 提交 。 这 种 线性 的 提交 会 很 好 地 推送 


到 Subversion 服 务 器 中 。 


如 果真 的 需要 在 不 同 的 Subversion 分 支 之 间 合 并 ， 尽 量 使 用 
Subversion 的 客户 端 (svn 1.5 版 本 或 以 上 ) 执行 ， 因 为 这 样 可 以 正确 地 
记录 svn:mergeinfo 属 性 。 当 Subversion 完 成 分 支 合 并 后 ， 在 git-svn 的 克隆 
库 中 执行 git svn rebase 命 令 获 取 最 新 的 Subversion 提 交 并 变 基 到 相应 的 跟 


第 5 篇 “搭建 Git 服 务 器 


如 果 不 是 要 和 他 人 协同 开发 ，Git 根 本 就 不 需要 架设 服务 器 ， 因 为 
Git 可 以 直接 使 用 本 地 路 径 操 作 本 地 的 版 本 库 及 完成 本 地 版 本 库 间 的 协 
同 。 





但 是 如 果 需 要 和 他 人 分 至 版 本 库 、 协 作 开 发 ， 或 者 想 要 通过 网 络 为 
个 人 的 版 本 库 建立 一 个 远程 容 灾 备份 ， 殊 会 涉及 服务 嚣 搭建， 以 及 使 用 
特定 的 网 络 协议 操作 Git 库 。 


Git 文 持 的 协议 很 丰富 ， 架 设 服 务 器 的 选择 也 很 多 ， 不 同 的 方案 有 
痢 各 目的 优 缺 后 ， 如 下 表 所 示 。 


Git 服 务 器 架设 方案 对 照 表 


EEFIP Git-daemon SSH Gitosis/Gitolite 








服务 架设 简单 中 等 简单 复杂 
匿名 读 取 支持 支持 否 - 否 、 
身份 认证 支持 否 支持 支持 
版 本 库 写 操作 支持 否 支持 支持 
企业 级 授权 否 否 否 支持 
远程 建 库 否 否 否 支持 








注 : *SSH 协 议和 基于 SSH 的 Gitolite 等 可 以 通过 空 口令 账号 实现 匿名 


访问 。 


第 27 章 ”使 用 HTTP 协 议 





HTTP 协 议 是 版 本 控制 非常 重要 的 一 种 协议 ， 具 有 安全 《使 用 
HTTPS 的 情况 下 ) 、 方 便 〈 可 以 跨越 防火 墙 ) 等 优点 。Git 在 1.6.6 版 本 
之 前 对 HTTP 协议 的 支持 有 限 ， 是 哑 协 议 ， 访 问 效率 低 ， 但 是 在 1.6.6 之 
后 ， 通 过 一 个 CGI 实现 了 智能 的 HTTP 协 议 文 持 。 


27.1 哑 传 输 协 议 


在 Git 1.6.6 之 前 ， 若 要 通过 HTTP 协 议 提 供 Git 服 务 ， 简 单 到 直接 找 
由 Git 版 本 库 到 Web 服 务 器 中 就 可 以 了 ， 即 将 Git 的 裸 版 本 库 〈 不 带 工 作 
区 ) 作为 一 个 web 静态 目录 直接 开放 给 用 户 即 可 上 。 


1. 只 读 的 HTTP 哑 协议 
如 下 的 Apache 配 置 ， 提 供 了 Git 版 本 库 的 只 读 访 问 服务 : 


Alias /git /path/to/repos 
<Directory /path/to/repos> 
Options FollowSymLinks 
AllowOverride None 
Order allow, deny 
Allow from all 
</Directory> 





当 用 户 执行 git clone http://server/git/myrepo.git 时 ， 实 际 访 问 的 是 服 
器 端 /path/tomrepos/myrepo.git 路 径 中 的 版 本 库 。 





以 Web 服 务 器 静态 目录 方式 提供 Git 服 务 ， 对 Git 版 本 库 有 一 个 特别 
的 要 求 ， 即 版 本 库 目 录 下 必须 存在 两 个 索引 文件 。 其 中 一 个 是 文 
件 .git/info/refs， 包 含 了 版 本 库 中 所 有 引用 的 列表 ， 且 包含 引用 对 应 的 
SHA1 哈 希 值 。 另 外 一 个 文件 是 .git/objects/info/packs， 包 含 了 所 有 打包 
文件 的 路 径 ， 以 便 在 对 象 库 打包 后 ， 能 够 通过 该 索引 文件 找到 打包 文 
件 。 





这 是 因为 在 Web 旺 协议 下 ， 作 为 客户 端 的 Git 类 似 于 一 个 web 浏览 
器 ， 远 程 的 Web 服 务 器 只 提供 Git 版 本 库 文件 的 静态 访问 ， 而 不 像 其 他 
Git 智 能 服务 器 那样 能 够 提供 帮助 以 获取 Git 版 本 库 的 引用 和 对 象 库 文 
件 。 即 作为 Web 客 户 端的 Git 仅 凭 一 己 之 力主 动 到 服务 器 上 抓 取 文 件 。 一 
旦 严格 配置 的 Web 服 务 器 禁止 目录 浏览 (最 安全 和 最 常用 的 配置 ) ， 如 
果 不 通过 事先 约定 的 索引 文件 (.git/info/refs 和 .git/objects/info/packs 文 
件 ) ，Git 作 为 Web 客 户 端 是 无 法 获得 版 本 库 的 引用 列表 和 打包 文件 列表 
的 。 





在 Git 版 本 库 中 创建 这 两 个 索引 文件 很 简单 ， 只 要 执行 git update- 
server-info 命 令 即 可 。 但 是 要 随 着 版 本 库 的 更 新 不 断 地 维 扩 .git/info/refs 
和 .git/objects/info/packs 这 几 个 文件 ， 以 便 使 用 呼 协议 的 Git 客 户 端 始终 能 
够 正常 地 访问 Git 版 本 库 可 不 是 一 件 简单 的 工作 。 季 好 Git 提 供 了 钩子 脚 
本 扩展 机 制 ， 可 以 实现 随 着 Git 版 本 库 的 更 新 同步 地 更 改 这 几 个 文件 。 








在 版 本 库 的 钧 子 脚本 目录 .git/hooks 中 ， 创 建 一 个 名 为 post-update 的 
钓 子 脚本 。 实 际 上 在 钧 子 脚本 的 目录 中 已 经 存在 一 个 示例 脚本 post- 
update.sample， 直 接 将 其 重 命名 为 post-update， 并 将 其 设置 为 可 执行 即 
可 。 肢 本 post-update 非 常 简单 ， 内 容 如 下 : 








#!1/bin/sh 
exec git update-server-info 


2. 可 读 写 的 HTTP 呈 协议 


上 面 配 置 的 HTTP 哑 协议 只 提供 Git 版 本 库 的 只 读 访 问 ， 如 果 需 要 提 
供 可 写 的 Git 版 本 库 服务 ， 即 允许 远程 客户 并 推送 ， 那 就 还 需要 在 
Apache 中 为 版 本 库 逐 一 启用 WebDAV 支 持 。 例 如 Apache 中 的 配置 如 下 : 





Alias /git /path/to/repos 

<Directory /path/to/repos> 
Options FollowSymLinks 
AllowOverride None 
Order allow, deny 
allow from all 

</Directory> 

<Location /git/myrepos.git> 
DAV on 
AuthType Basic 
AuthName "Git" 
AuthBasicProvider file 
AuthUserFile /path/to/file/passwd 
AuthGroupFile /path/to/file/group 
Require group git 
Satisfy All 

</Location> 








无 论 是 只 读 还 是 支持 写 入 ， 以 HITP 哑 传输 协议 配置 的 Git 服 务 器 都 
有 着 非常 明显 的 缺点 : 





(1) 数据 传输 效率 低 。 当 版 本 库 经 过 整理 ， 各 个 零散 的 提交 文件 
被 打包 后 ， 只 获取 东 一 个 或 菜 几 个 提交 也 需要 对 整个 打包 文件 进行 传 


输 ! 





(2) 传输 过 程 无 进度 显示 。 哑 协议 在 Git 操 作 过 程 中 不 能 像 其 他 协 
议 那 样 显示 进度 ， 在 操作 大 的 版 本 库 时 非 第 不 便 。 





(3) 为 版 本 库 提 供 写 操作 需要 对 每 个 版 本 库 进 行 单独 配置 。 缺 乏 
类 似 Subversion 的 WebDAV 插 件 ， 使 得 需要 为 每 个 Git 库 逐一 进行 设置 。 





(4) 需要 在 服务 嚣 端 手工 创建 版 本 库 ， 而 不 能 通过 远程 推送 操作 
来 实现 在 客户 器 发 起 版 本 库 的 创建 。 





(5) Git 客 户 端 不 像 Subversion 那 样 提供 口令 缓存 机 制 ， 如 果 要 避 
免 每 次 操作 时 频繁 地 输入 口令 ， 需 要 在 URL 中 记录 明文 口令 。 





git clone https://username:password@server/path/to/repos/myrepo.git 





下 面 将 要 介绍 的 智能 HTTP 协 议 则 没有 上 面 所 述 的 大 多 数 1、2 和 3 缺 
上 护 ， 在 很 大 程度 上 完善 了 在 HTTP 协 议 上 架设 Git 版 本 库 的 用 户 体 验 。 





[1] 实际 上 还 需要 执行 git update-setvet-info 命 令 ， 以 更 新 版 本 库 中 的 几 个 
索引 文件 。 


27.2 ”智能 HTTP 协 议 


Git 1.6.6 之 后 的 版 本 提供 了 针对 HTTP 协 议 的 CGI 程序 git-http- 
backend， 实 现 了 智能 的 HTTP 协 议 支 持 。 但 同时 要 求 Git 客 户 端 的 版 本 不 
低 于 1.6.6。 


查看 文件 git-http-backend 的 安装 位 置 ， 可 以 用 如 下 命令 。 





$ ls $(git --exec-path)/git-http-backend 
/usr/1lib/git-core/git-http-backend 





更 改 Apache 的 配置 文件 ， 以 使 用 CGI 提供 智能 Git 访 问 服 务 。 相 关 的 
Apache 配 置 如 下 : 





SetEnv GIT_PROJECT_ROOT /path/to/repos 
SetEnv GIT_HTTP_EXPORT_ALL 
ScriptAlias /git/ /usr/lib/git-core/git-http-backend/ 





说 明 : 
“ 第 一 行 设置 版 本 库 的 根 目 录 为 /path/to/repos。 


“第 二 行 设置 所 有 版 本 库 均 可 访问 ， 无 论 在 版 本 库 中 是 否 存 在 git- 


daemon-export-ok 文 件 。 





默认 只 有 在 版 本 库 目 录 中 存在 git-daemon-export-ok 文 件 时 ， 该 版 本 


库 才 可 以 访问 。 这 个 文件 是 git-daemon 服 务 的 一 个 特性 。 


` 第 三 行 ， 就 是 使 用 名 为 githttp-backend 的 CGI 脚本 来 响应 客户 端的 


请 求 。 
当 访 问 http://server/git/myrepos.git 时 ， 即 由 此 CGI 提供 服务 。 
1. 写 操作 授权 


上 面 的 配置 只 能 提供 版 本 库 的 读 取 服务 ， 厦 想 提供 基于 HTTP 协 议 
的 写 操作 ， 必 须 添 加 认证 配置 指令 。 用 户 通 过 认证 后 才能 对 版 本 库 进行 
写 操作 。 








下 面 的 Apache 配 置 中 ， 在 前 面 配置 的 基础 上 为 Git 写 操作 提供 授 
权 : 





<LocationMatch "^/git/.*/git-receive-pack$"> 
AuthType Basic 
AuthName "Git Access" 
AuthBasicProvider file 
AuthUserFile /path/to/passwd/file 


</LocationMatch> 





2. 读 和 写 均 需 授权 





如 果 需 要 对 读 操 作 也 进行 授权 ， 那 就 更 简单 了 。 下 面 的 配置 通过 一 
个 Location 语 句 实现 了 对 路 径 /path/private 下 版 本 库 的 读 写 授权 。 





<Location /git/private> 


AuthType Basic 

AuthName "Git Access" 
AuthBasicProvider file 
AuthUserFile /path/to/passwd/file 


</Location> 





3. 对 静态 文件 的 直接 访问 


如 果 对 静态 文件 的 访问 不 经 过 CGI 程序 ， 直 接 由 Apache 提 供 服务 ， 
会 提高 访问 性 能 


下 面 的 Apache 配 置 设置 了 直接 通过 Apache 〈 绕 过 CGI) 访问 Git 版 本 
库 中 对 象 库 下 的 文件 。 











SetEnv GIT_PROJECT_ROOT /path/to/repos 
AliasMatch 人 ^/git/(.*/objects/[0-9a-f]{2}/[0-9a-f]{38})$ /path/to/repos/$1 
AliasMatch 人 ^/git/(.*/objects/pack/pack-[0-9a-f]{40}.(pack|idx))$ /path/to/repos/$1 
ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/ 





Git 的 智能 HITP 服 务 彻底 打破 了 以 前 哑 传 输 协 议 给 HITP 协 议 市 来 
的 恶劣 印象 ， 让 HTTP 协 议 成 为 Git 服 务 的 一 个 重要 选项 。 但 是 在 授权 的 
管理 上 ， 智 能 HTTP 服 务 仅仅 依赖 Apache 自 身 的 授权 模型 ， 相 比 后 面 要 
介绍 的 Gitosis 和 Gitolite， 可 管理 性 要 弱 得 多 。 表 现 如 下 : 





创建 版 本 库 只 能 在 服务 器 端 进 行 ， 不 能 通过 远程 客户 端 进 行 。 


配置 认证 和 授权 ， 也 只 能 在 服务 器 端 进行 ， 不 能 在 客户 端 远 程 配 


` 版 本 库 的 写 操作 授权 只 能 进行 非 0 即 1 的 授权 ， 不 能 针对 分 支 其 至 


路 径 进 行 授 权 。 


如 果 需 要 企业 级 的 版 本 库 管 理 ， 可 以 考虑 后 面 介 绍 的 基于 SSH 协 议 
的 Gitolite 或 Gitosis。 


27.3 ”Gitweb 服 务 器 


前 面 介 绍 的 HITP 哑 协议 和 智能 协议 服务 架设 ， 都 可 以 用 于 提供 Git 
版 本 库 的 读 写 服务 ， 而 本 节 介 绍 的 Gitweb 作 为 一 个 Web 应 用 ， 只 提供 版 
本 库 的 图 形 化 浏览 功能 ， 而 不 能 提供 版 本 库 读 写 访问 的 功能 。 


Gitweb 是 用 Perl 语 言 开发 的 CGI 脚 本 ， 既 可 以 通过 配置 染 设 于 Web 服 
务 器 下 ， 也 可 以 无 须 任 何 配置 针对 单独 Git 版 本 库 即 时 启动 。Gitweb 文 
持 多 个 版 本 库 ， 可 以 对 版 本 库 进 行 目 录 浏 览 〈 包 括 历史 版 本 ) ， 可 以 查 
看 文件 内 容 ， 碍 看 提交 历史 ， 提 供 搜索 及 RSS feed 支持 ， 也 可 以 提供 目 
录 文 件 的 打包 下 载 等 。 图 27-1 就 是 kernel.org 上 的 Gitweb 示 例 。 





文件 (E) ”编辑 (E) 查看 (V) 历史 (S) 书签 (B) ” 拆 分 (P) 工具 ( 工 ) 帮助 (H) 
寺 vEONY Mv |;;http://gitkernel.org/?p=linux/kernel/git/stable/linux-2. 国 四 I? v | «| gitweb v| 雪 vv 
;77 git.kernel.org - linux/kernel/git... 加 人 


/pub/scm / linux/kernel/git/stable/linux-2.6-stable.git / summary re 有 
summary | shortiog | lo0g | commit | commitdiff | tree commt EF search 口 re 





description Unified stable trees mirror 


owner Linux Kemel Distribution System 
last change Tue, 16 Nov 2010 02;31:02 +0000 
URL git/git kermnel orglpublscm/linuxkernel/gitistable/linux-.2.6.stable git 


http-/git kernel org/lpubjscm/linuwkermel/gitistable/linux-2.6.stable git 
https-//git kemel org/pub/scmMinux/kernel/gitistable/linux.2.6.stable git 


shortiog 
5hoursago Linus Torvalds Linux 2.6.37-rc2 master | NNO v2c3rrcz 
8hoursago Enc Pans capabilities/syslog: open code cap_ ey logic to.. 


li0hoursago Linus Torvalds Merge branch ‘omap-fixes-for-linus' of git://git. 人 
i0 hoursago Linus Torvalds Merge branch 'hwmon-for-linus' of git://git./linux... 
10 hours ago Linus Torvalds Merge branch 'i2c-for-linus of git://git./linuwWkernel... eet|csommii| tee 
10 hoursago Linus Torvalds Merge branch 'for-linus' of git://git./linux/kernel... 
li0 hours ago JeanDelvare i2c: Sanity checks on adapter registration 

ID hoursago JeanDelvare i2c: Mark i2c_adapter.id as deprecated 


也 完成 如 FoxyProxy: 禁用 圈 也 | 














|commieirf | tree | snapshot v 


加 人 A| 沼 现 在 :9°CC |S$K:12°C CO Se. 














ol 


图 27-1 Gitweb 界 面 (kernel.org) 
27.3.1 ”Gitweb 的 安装 


1. 使 用 包 管 理 器 安装 


各 个 Linux 平 台大 都 提供 了 Gitweb 软 件 包 ， 可 以 使 用 相应 的 包 管 理 
器 进行 安装 。 例 如 在 Debian/Ubuntu 上 安装 Gitweb: 





$ sudo aptitude install gitweb 





安装 Gitweb 后 会 在 系统 中 创建 下 列 文件 : 
IE 

. Apache 配 置 文件 : /etc/apache2/conf.d/gitweb 
.CGI 脚本 : /ust/share/gitweb/index.cgi 

. 其 他 附属 文件 : /ust/share/gitweb/* 

` 图 片 和 css 等 


其 中 配置 文件 /etc/apache2/conf.d/gitweb 用 于 完成 和 Web 服 务 器 
Apache2 的 整合 。 当 Apache2 重 启 后 ， 就 可 以 通过 URL 地 
址 http://server/gitweb 访问 Gitweb 服 务 。 


2. 使 用 Gift 源码 安装 


Gitweb 的 代码 位 于 Git 的 源码 库 中 ， 如 果 Git 是 从 源码 进行 安装 的 ， 
那么 Gitweb 应 该 已 经 安装 好 了 。 通 过 下 面 的 命令 可 以 查看 Gitweb 的 安装 
位 置 : 





$ ls -F $(dirname $(dirname $(git --html-path)))/gitweb 
gitweb.cgi* static/ 

$ echo $(dirname $(dirname $(git --html-path)))/gitweb 
/usr/share/gitweb 





Gitweb 虽 然 已 经 安装 ， 但 是 尚未 和 Web 服务 器 整合 。 在 Apache 的 配 
置 文 件 中 添加 如 下 配置 ， 重 启 Apache 后 ， 即 可 以 用 地 址 /gitweb 来 访问 
Gitweb 服 务 。 





Alias /gitweb /usr/share/gitweb 
<Directory /usr/share/gitweb> 
Options FollowSymLinks +ExecCGI 
AddHandler cgi-script .cgi 
DirectoryIndex index.cgi gitweb.cgi 
Order Allow, Deny 
Allow from all 
</Directory> 





27.3.2 ”Gitweb 的 配置 


编辑 /etc/gitweb.conf， 更 改 Gitweb 的 默认 设置 : 


` 版 本 库 的 根 目录 。 





$projectroot = "/var/cache/git",; 





. 设置 版 本 库 访 问 URL。 


Gitweb 可 以 为 每 个 版 本 库 显 示 克 隆 该 版 本 库 的 URL 地 址 ， 可 以 设置 
多 个 。 





@git_ base url list = ("git://bj.ossxp.com/git", "http://bj.ossxp.com/git"); 





设置 首页 模板 文件 。 该 文件 为 HTMIL 格 式 ， 其 内 容 将 显示 在 首页 
上 。 如 果 使 用 相对 路 径 ， 则 相对 于 CGI 脚本 所 在 的 目录 。 





$home_text = "indextext.html"; 





定制 首页 模板 。 下 面 是 我 公司 内 部 使 用 的 Gitweb 首 页 模板 。 





<html> 
<head> 
</head> 
<body> 
<h2> 北 京 群英 汇 信息 技术 有 限 公司 - git 代码 库 </h2> 
<ul> 
<1i> 点 击 版 本 库 ， 进 入 相应 的 版 本 库 页 面 ， 有 URL 指向 一 个 git://..， 的 检 出 链接 </1i> 
<1i> 使 用 命令 git clone git://... 来 克隆 一 个 版 本 库 </1i> 
<1i> 对 于 名 称 中 含有 <i>-gitsvn</i> 字样 的 代码 库 ， 是 用 git-svn 从 svn 代码 库 镜 像 而 来 的 。 对 于 
<ul> 
<1i> 要 将 git 库 的 远程 分 支 ( .git/ref/remotes/*) 也 同步 到 本 地 ! 
<pre> 
$ git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/*' 
$ git fetch 
</pre> 
</1i> 
<1i> 如 果 需 要 克隆 库 和 “Subversion 同步 。 用 git-svn 初始 化 代码 库 
</ul> 
</1i> 
</ul> 
</body> 
</html> 






























































































































































得 相关 配置 和 源 保持 一 至 


nh 





























` 版 本 库 列 表 。 





默认 扫描 版 本 库 根 目录 得 找 厂 本 库 。 如 果 版 本 库 非 常 多， 这 个 碍 找 
过 程 可 能 很 耗 时 ， 可 以 提供 一 个 文本 文件 包含 版 本 库 的 列表 加 速 Gitweb 
显示 初始 化 。 


7 





$projects_ list = "/home/git/gitosis/projects.1ist"; 





后 面 介绍 的 Gitosis 和 Gitolite 都 可 以 目 动 生成 这 么 一 个 版 本 库 列 表 ， 
供 Gitweb 使 用 。 


. Gitweb 菜 单 定制 。 
Git 羔 单 定制 项 很 多 ， 下 面 选 取 几 个 典型 配置 进行 介绍 。 


. 在 ttee view 文 件 的 穷 边 显示 追溯 (blame) 链接 。 





$feature{'blame'}{'default'} = [1]; 
$feature{'blame'}{'override'} = 1; 





. 通过 版 本 库 的 配置 文件 config 对 版 本 库 在 Gitweb 中 是 否 显 示 追 
溯 进 行 单独 设置 。 


下 面 的 设置 覆盖 Gitweb 的 全 局 设置 ， 不 对 该 项 目 显示 blame 沫 单 。 





[gitweb] 
blame = 0 





. 为 每 个 tree 添 加 快照 (snapshot) 下 载 链 接 。 


$feature{'snapshot'}{'default'} = 'tgz']; 
$feature{'snapshot'}{'override'} = 





27.3.3 ”版 本 库 的 Gitweb 相 关 设 置 


可 以 通过 Git 版 本 库 下 的 配置 文件 ， 定 制版 本 库 在 Gitweb 下 的 显 


` 文件 description。 
提供 一 行 简短 的 Git 库 描述 ， 显 示 在 Gitweb 版 本 库 列表 中 。 


也 可 以 通过 config 配 置 文件 中 的 gitweb.description 进 行 设置 ， 但 是 文 
1 


` 文件 README.html。 

提供 更 详细 的 项 目 描述 ， 显 示 在 Gitweb 项 目 页 面 中 。 
文件 cloneutl。 

版 本 库 访问 的 URL 地 址 ， 一 行 一 个 。 
. 文件 config。 


通过 [gitweb] 小 节 的 配置 ， 禾 新 Gitweb 的 全 局 设置 : 


.gjitweb.ownet 用 于 显示 版 本 库 的 创建 者 。 


gitweb.description 显 示 项 目的 简短 描述 ， 也 可 以 通过 description 


文件 来 提供 。 (文件 优先 ) 
gitweb.utl 显 示 项 目的 URL 列 表 ， 也 可 以 通过 cloneurl 文 件 来 提 
供 。 (文件 优先 ) 


27.3.4 ”即时 Gitweb 服 务 


如 果 安 装 有 lighttpd 帆 一 一 轻 量 级 Web 服 务 器 ， 甚 至 可 以 无 须 任何 
配置 ， 当 在 工作 区 中 运行 下 面 的 命令 时 ， 自 动用 Web 浏览 器 打开 URL 地 
址 : http:/127.0.0.1:1234/ ， 访 问 即 时 启动 的 Gitweb 服 务 。 











$ git instaweb 





可 以 通过 Git 配 置 变 量 对 即时 启动 的 Gitweb 服 务 进行 设置 ， 例 如 用 
instaweb.port 配 置 变量 设置 默认 Web 服 务 端口 〈 默 认为 1234) 。 





[1] http:/ /www.lighttpd.net/ 


第 28 章 ”使 用 Git 协 议 


Git 协 议 是 提供 Git 版 本 库 只 读 服 务 的 最 党 用 的 协议 ， 也 是 非常 易 用 
和 易于 配置 的 协议 。 该 协议 的 缺点 吏 是 不 能 提供 身份 认证 ， 而 且 一 般 也 
不 提供 写 入 服务 。 


28.1 ”Git 协议 语法 格式 


Git 协 议 的 语法 格式 如 下 。 








语法 : git://<server>[:<port>]/path/to/repos.git/ 





说 明 : 
. 端口 为 可 选项 ， 默 认 端 口 为 9418。 


` 版 本 库 路 径 /path/to/repos.git 的 根 目 录 并 不 一 定 是 系统 的 根 目 
录 ， 可 以 在 git-daemon 启 动 时 用 参数 --base-path 来 指定 根 目录 。 如 果 git- 
daemon 没 有 设置 根 目 录 ， 则 对 应 于 系统 的 根 目 录 。 


28.2 ”Git 服 务 软件 


Git 服 务 由 名 为 git-daemon 的 服务 软件 提供 。 昌 然 git-daemon 也 可 以 
支持 写 操作 ， 但 因为 git-daemon 没 有 提供 认证 支持 ， 因 此 很 少 有 人 胆敢 
配置 git-daemon 来 提供 匿名 的 写 服 务 。 使 用 git-daemon 提 供 的 Git 版 本 库 
只 读 服 务 效率 很 高 ， 而 且 是 一 种 智能 协议 ， 操 作 过 程 有 进度 显示 ， 远 比 
HTTP 哑 通信 协议 方便 《〈Git 1.6.6 之 后 的 版 本 已 经 文 持 智能 HTTP 通信 协 
议 ) 。 因 此 gitrdaemon 很 久 以 来 ， 一 直 是 Git 版 本 库 只 读 服 务 的 首选 。 











Git 软 件 包 本 身 提 供 了 git-daemon， 因 此 只 要 安装 了 Git， 一 般 束 已 经 
安装 了 git-daemon。 默 认 git-daemon 并 没有 运行 ， 需 要 对 其 进行 配置 ， 以 
服务 的 方式 运行 。 下 面 介 绍 两 种 不 同 的 配置 运行 方式 。 














28.3 ”以 inetd 方 式 配 置 运 行 


最 简单 的 方式 是 以 inetd 服 务 的 方式 运行 git-daemon。 在 配置 文 
件 /etc/inetd.conf 中 添加 如 下 设置 : 





git stream tcp nowait nobody /usr/bin/git 
git daemon --inetd --verbose --export-all 
/gitroot/foo /gitroot/bar 





说 明 : 
以 nobody 用 户 身份 执行 git daemon 服 务 。 


默认 git-daemon 只 对 包含 文件 git-daemon-expott-ok 的 版 本 库 提供 服 
务 。 使 用 参数 --export-all 后 ， 无 论 版 本 库 是 否 存 在 标识 文件 git-daemon- 
export-ok， 都 对 版 本 库 提供 Git 访 问 服务 。 


` 后 面 的 两 个 参数 是 版 本 库 根 目录 ， 用 户 只 可 以 访问 指定 目录 下 的 
Git 版 本 库 。 


例如 可 以 访问 git://server/gitroot/foo/project1.git 和 
git://server/gitroot/bar/project2.git， 但 是 git://server/others/project3.git 是 访 


问 不 到 的 。 


如 果 版 本 库 的 路 径 比 较 深 有 什么 办 法 能 在 用 户 访 问 时 提供 短 一 些 








的 URL 地 址 呢 ? 可 以 使 用 参数 --base-path=<path> 建 立 版 本 库 根 目录 映 
射 ， 例 如 下 面 的 inetd 的 配置 : 





git stream tcp nowait nobody /usr/bin/git 
git daemon --inetd --verbose --export-all 
--base-path=/var/cache /var/cache/git 





在 上 面 的 配置 中 ， 设 置 提 供 厂 本 库 服 务 的 路 径 为 /varcache/git， 但 
为 配置 了--base-path=/var/cache 参 数 ， 在 实际 访问 时 用 户 所 请 求 的 Git 
版 本 库 路 径 都 会 添加 这 个 前 级 ， 然 后 再 到 指定 的 目录 中 去 寻找 。 例 如 当 
用 户 访问 git://server/git/myrepos.git 时 ， 实 际 访问 的 路 径 


是 /var/cache/git/myrepos.git。 


28.4 ”以 runit 方 式 配 置 运 行 


runit 11 是 类 似 于 sysvinit 的 服务 管理 进程 ， 但 是 更 为 简单 。 在 
Debian/Ubuntu 上 的 软件 包 git-daemon-run 就 是 基于 runit 启 动 git-daemon 服 


务 。 


` 安装 git-daemon-run: 





$ sudo aptitude install git-daemon-run 





" 配置 git-daemon-run: 


默认 的 服务 配置 文件 /etc/sv/git-daemon/run。 和 之 前 的 inetd 运 行 方 
式 相 比 ， 以 独立 的 服务 进程 启动 ， 速 度 更 快 。 





#!/bin/sh 

exec 2>&1 

echo 'git-daemon starting.' 

exec chpst -ugitdaemon \ 
"$(git --exec-path)"/git-daemon --verbose --export-all \ 
--base-path=/var/cache /var/cache/git 








默认 版 本 库 中 需要 存在 文件 git-daemon-export-ok，git-daemon 才 对 
此 版 本 库 提 供 服务 。 不 过 可 以 通过 启动 git-daemon 时 提供 的 参数 --export- 
all， 无 论 版 本 库 是 否 存 在 标识 文件 git-daemon-export-ok， 都 对 版 本 库 提 
供 git 访 问 服 务 。 











git-daemon 提 供 很 多 参数 ， 在 此 没有 一 一 介绍 ， 可 以 运行 git help 
daemon 在 控制 台 查 看 git-daemon 帮 助 ， 或 者 运行 git help--web daemon 碍 
看 HTML 格 式 的 帮助 。 


通过 git-daemon 提 供 的 Git 访 问 协 议 存 在 着 局 限 性 : 


. 不 支持 认证 。 管 理 员 可 以 做 的 大 概 只 是 配置 防火 墙 ， 限制 茶 个 网 
段 用 户 的 使 用 。 


只 能 提供 匿名 的 版 本 库 读 取 服 务 。 因 为 写 操作 没有 授权 控制 ， 因 
此 一 般 不 用 来 提供 写 操 作 。 


[1] http://smarden.org/runit/ 


第 29 半 ”使 用 SSH 协 议 


SSH 人 协议 用 于 为 Git 提 供 远 程 读 写 操作 ， 是 远程 写 操作 的 标准 服务 ， 
在 智能 HTTP 协 议 出 现 之 前 ， 甚 至 是 写 操作 的 唯一 标准 服务 。 





29.1 SSH 协 议 语法 格式 


对 于 拥有 shell 登 录 权限 的 用 户 账号 ， 可 以 用 下 面 的 语法 访问 Git 版 本 
库 : 





语法 1: ssh://[<username>@]<server>[:<port>]/path/to/repos/myrepo.git 
语法 2: [<username>@]<server>:/path/to/repos/myrepo.git 








说 明 : 


SSH 协议 地 址 格式 可 以 使 用 两 种 不 同 的 写法 ， 第 一 种 是 使 用 ssh:// 
开头 的 标准 的 SSH 协 议 URL 写 法 ， 另 外 一 种 是 SCP 格 式 的 写法 。 


两 种 写法 均 可 ，SSH 协 议 标 准 URL 写 法 稍 嫌 复杂 ， 但 是 对 于 非 标 准 
SSH 端 口 〈 非 22 端 口 ) ， 可 以 通过 URL 给 出 端口 号 。 





<username> 是 服务 器 <servet> 上 的 用 户 账 号 。 








如 果 省 上 略 用 户 名 ， 则 默认 使 用 当前 登录 用 户 名 配置 和 使 用 了 主机 
别名 的 除外 ) 。 


. <pott> 为 SSH 协 议 端口 ， 默 认为 22。 


因为 只 有 语法 1 才能 在 URL 中 提供 端口 ， 因 此 如 果 使 用 非 默 认 端 口 
22， 最 好 使 用 语法 1。 当 然 使 用 语法 2 也 可 以 实现 ， 但 是 要 通过 








~/.ssh/config 配 置 文件 设置 主机 别名 。 


` 路 径 /path/to/repos/myrepo.git 是 服务 器 中 版 本 库 的 绝对 路 径 。 若 
用 相对 路 径 则 是 相对 于 username 用 户 的 主 目录 而 言 的 。 


. 如 果 采 用 口令 认证 ， 不 能 像 HTTPS 协 议 那 样 可 以 在 URL 中 同时 给 
出 登录 名 和 口令 ， 必 须 在 每 次 连接 时 输入 口令 。 


- 如 果 采 用 公 钥 认证 ， 则 无 须 输入 口令 。 


29.2 ”服务 架设 方式 比较 


SSH 协 议 有 两 种 方式 来 实现 Git 服 务 。 第 一 种 是 用 标准 的 SSH 账 号 访 
问 版 本 库 。 即 用 户 账号 可 以 直接 登录 到 服务 器 获得 shell。 对 于 这 种 使 用 
标准 SSH 账 号 的 方式 ， 直 接 使 用 标准 的 SSH 服 务 就 可 以 了 ， 无 须 歼 述 。 











第 二 种 实现 方式 是 所 有 用 户 都 使 用 同一 个 专用 的 SSH 账 号 访问 版 本 
库 ， 访 问 时 通过 公 钥 认证 的 方式 。 虽 然 所 有 用 户 用 同一 个 账号 访问 ， 但 
可 以 通过 在 建立 连接 时 所 用 的 不 同 公 钼 来 区 分 不 同 的 用 户 身 份 。Gitosis 
和 Gitolite 就 是 实现 该 方式 的 两 个 服务 占 软 件 。 








标准 SSH 账 号 和 专用 SSH 账 号 这 两 种 实现 方式 的 区 别 见 表 29-1。 


表 29-1 不 同 SSH 服 务 架 设 方式 对 照 表 





标准 SSH Gitosis/Gitolite 
账号 每 个 用 户 一 个 账号 所 有 用 户 共用 同一 个 账号 
认证 方式 口令 或 公 钥 认 证 公 钥 认证 
登录 到 shell 是 否 
安全 性 差 好 
管理 员 需 要 shell 是 否 
版 本 库 路 径 相对 路 径 或 绝对 路 径 相对 路 径 
授权 方式 操作 系统 中 用 户 组 和 目录 权限 通过 配置 文件 授权 
分 支 写 授权 否 Gitolite 
路 径 写 授权 否 Gitolite 


架设 难 易 度 简单 复杂 





实际 上 ， 标 准 SSH 也 可 以 用 公 钥 认证 的 方式 实现 所 有 用 户 共用 同一 
个 账号 ， 不 过 这 类 似 于 把 一 个 公共 账号 的 登录 口令 同时 告诉 给 多 个 人 。 
具体 操作 过 程 如 下 : 


(1) 在 服务 器 端 〈server) 创建 一 个 公共 账号 ， 例 如 anonymous。 


(2) 管理 员 收 集 需 要 访问 git 服 务 的 用 户 公 铀 。 如 : userl.pub、 


User2.pub。 


(3) 使 用 ssh-copy-id 命 令 将 各 个 git 用 户 的 公 钥 远程 加 入 服务 器 
(server) 的 公 钥 认证 列表 中 。 


远程 操作 ， 可 以 使 用 ssh-copy-id 命 令 。 





$ ssh-copy-id -i useri1.pub anonymous@server 
$ ssh-copy-id -i user2.pub anonymous@server 





如 果 直 接 在 服务 器 上 操作 ， 则 直接 将 文件 追加 到 authorized_keys 
文件 中 。 





$ cat /path/to/useri.pub >> ~anonymous/.ssh/authorized_keys 
$ cat /path/to/user2.pub >> ~anonymous/.ssh/authorized_keys 





(4) 在 服务 器 端的 anonymous 用 户主 目录 下 建立 git 库 ， 就 可 以 实现 
多 个 用 户 利用 同一 个 系统 账号 (anonymous) 访问 Git 服 务 了 。 


这 样 做 除了 不 必 逐 一 设置 账号 ， 以 及 用 户 无 须 口 令 认 证 之 外 ， 标 准 


SSH 部 署 Git 服 务 的 缺点 一 个 也 不 少 ， 而 且 因为 用 户 之 间 无 法 区 分 ， 更 无 
法 针对 用 户 进行 授权 。 


下 面 重 点 介绍 一 下 SSH 公 钥 认 证 ， 因 为 它们 是 后 面 即 将 介绍 的 
Gitosis 和 Gitolite 服 务 嚣 软件 的 基础 。 


29.3 ”关于 SSH 公 和 钥 认 证 


SSH 公 钥 认证 是 一 种 非常 安全 且 免 口令 的 认证 方式 。 关 于 公 钥 认证 
的 原理 ， 维 基 百 科 上 的 这 个 条 目 是 一 个 很 好 的 起 点 : 


http://en.wikipedia.org/wiki/Public-key_cryptography 





为 实现 公 钥 认证 ， 作 为 认证 的 客户 端 一 方 需要 拥有 两 个 文件 ， 即 公 
钥 / 私 钥 对 。 一 般 公 钥 / 私 钥 对 文件 创建 在 用 户 的 主 目录 下 的 .ssh 目 录 中 。 
如 果 用 户主 目录 下 不 存在 .ssh 目 录 ， 说 明 SSH 公 和 钥 / 私 钥 对 尚未 创建 。 可 
以 用 下 面 的 这 个 命令 创建 : 





$ ssh-keygen 


该 命令 会 在 用 户主 目录 下 创建 .sh 目录 ， 并 在 其 中 创建 两 个 文件 : 


* id_rsa 








私 钥 文 件 。 是 基于 RSA 算 法 创建 的 。 该 私 钥 文 件 要 受 善 保管 不 要 沪 
漏 。 


id_fsa.pub 


公 钥 文件 。 和 id_rsa 文 件 是 一 对 儿 ， 访 文件 作为 公 钥 文件 可 以 公 


创建 了 自己 的 公 钥 / 私 钥 对 后 ， 就 可 以 使 用 下 面 的 命令 ， 实 现 无 口 
令 登 录 远 程 服务 器 ， 即 用 公 钥 认证 取代 口令 认证 。 





$ ssh-copy-id -i .ssh/id_rsa.pub <user>@<server> 





说 明 : 
. 该 命令 会 提示 输入 用 户 uset 在 server 上 的 SSH 登 录 口 令 


. 此 命令 执行 成 功 后 ， 再 以 user 用 户 用 ssh 命 令 登 录 server 远 程 主机 
时 ， 不 必 输 入 口令 可 直接 登录 。 


. 该 命令 实际 上 是 将 .ssh/id_rsa.pub 公 和 钥 文 件 追 加 到 远程 主机 server 


的 usef 主 目录 下 的 .ssh/authorized_keys 文 件 中 。 


检查 公 钥 认证 是 否 生效 ， 通 过 ssh 命 令 连 接 远程 主机 ， 正 常 的 话 应 
该 直接 登录 成 功 。 如 果 要 求 输入 口令 则 表明 公 钥 认证 配置 存在 问题 。 如 
果 SSH 登 录 存 在 问题 ， 可 以 通过 查看 服务 器 端的 warlog/auth.log 日 志 
件 进行 诊断 。 





29.4 关于 SSH 主 机 别名 


在 实际 应 用 中 ， 有 了 时 需要 使 用 多 套 公 钥 / 私 钥 对 ， 例 如 : 
` 使 用 默认 的 公 角 访问 服务 器 的 git 账 号 ， 可 以 执行 git 命 令 ， 但 不 
进行 shell 登 录 。 
. 使 用 特别 创建 的 公 负 访问 服务 器 的 git 账 号 ， 能 够 获取 shell， 登 录 
后 可 以 对 Git 服 务 器 软件 进行 升级 、 维 护 等 工作 。 
` 访问 Github (免费 的 Git 服 务 托管 商 ) 使 用 其 他 公 钥 〈( 非 默认 公 
钥 ) 。 
从 上 面 的 说 明 中 可 以 看 出 ， 用 户 可 能 拥有 不 只 一 套 公 钥 / 私 钥 对 。 


为 了 创建 不 同 的 公 钥 / 私 钥 对 ， 在 使 用 ssh-keygen 命 令 时 就 需要 通过 -f 参 
数 指定 不 同 的 私 钥 名 称 。 用 法 如 下 : 





$ ssh-keygen -f ~/.ssh/<filename> 





请 将 <filename> 蔡 换 为 有 意义 的 名 称 。 命 令 执行 完毕 后 ， 会 在 ~/.ssh 
目录 下 创建 指定 的 公 钥 / 私 钥 对 : 文件 <filename> 是 私 铀 ， 文 件 


<filename>.pub 是 公 乌 。 


将 新 生成 的 公 钥 添加 到 远程 主机 登录 用 户主 目录 下 


的 .sshyauthorized_keys 文 件 中 ， 就 可 以 使 用 新 创建 的 公 钥 建立 到 远程 主 
机 <server> 的 <user> 账 户 的 无 口令 登录 〈 采 用 公 钥 认证 ) 。 操 作 如 下 : 





$ ssh-copy-id -i .ssh/<filename>.pub <user>@<server> 








现在 用 户 存 在 多 个 公 钥 / 私 钥 对 ， 那 么 当 执 行 下 面 的 ssh 登 录 指 令 
时 ， 用 到 的 是 哪个 公 钥 呢 ? 





$ ssh <user>@<server> 





当然 是 默认 公 钥 ~/.ssh/id_rsa.pub。 那 么 如 何 用 新 建 的 公 钥 连接 


server 呢 ? 


SSH 的 客户 端 配 置 文件 ~/.ssh/config 可 以 通过 创建 主机 别名 ， 在 连接 
主机 时 选择 使 用 特定 的 公 钥 。 例 如 ~/.ssh/config 文 件 中 的 下 列 配置 : 





host bj 
user git 
hostname bj.ossxp.com 
port 22 
identityfile ~/.ssh/jiangxin 





执行 下 面 的 SSH 登 录 命令 : 





$ ssh bj 





或 者 执行 下 面 的 Git 命 令 : 





$ git clone bj:path/to/repos/myrepo.git 





虽然 这 两 条 命令 各 不 相同 ， 但 是 都 使 用 了 SSH 协 议 ， 以 及 相同 的 主 
机 别名 : bj。 参 考 上 面 在 ~/.ssh/config 文 件 中 建立 的 主机 别名 ， 可 以 做 出 
如 下 判断 : 





. 登录 的 SSH 主 机 名 为 bj.ossxp.com。 


. 登录 时 使 用 的 用 户 名 为 git。 


. 认证 时 使 用 的 公 铀 文件 为 ~/.ssh/jiangxin.pub。 


第 30 章 ”Gitolite 服 务 架 设 


Gitolite 是 一 款 Perl 语 言 开 发 的 Git 服 务 管理 工具 ， 通 过 公 钥 对 用 户 进 
行 认证 ， 并 能 够 通过 配置 文件 对 写 操 作 进 行 基于 分 文 和 路 径 的 精细 授 
权 。Gitolite 采 用 的 是 SSH 协 议 并 且 使 用 SSH 公 和 钥 认 证 ， 因 此 无 论 是 管理 
员 还 是 普通 用 户 ， 都 需要 对 SSH 非 常熟 悉 。 在 开始 之 前 ， 请 确认 您 已 经 


通读 过 第 29 章 “使 用 SSH 协 议 ”。 


Gitolite 的 官方 网 址 是 :http://github.com/sitaramc/gitolite 。 从 提交 日 
志 里 可 以 看 出 作者 是 Sitaram Chamarty， 最 早 的 提交 开始 于 2009 年 8 月 。 
作者 是 受到 了 Gitosis 的 启发 ， 开 发 了 这 款 功 能 更 为 强大 和 易于 安装 的 软 
件 。Gitolite 的 命名 ， 作 者 的 原意 是 Gitosis 和 lite 的 组 合 ， 不 过 因为 
Gitolite 的 功能 越 来 越 强大 ， 己 经 超越 了 Gitosis， 因 此 作者 笑称 Gitolite 可 
以 看 作 是 Github-lite 一 一 轻 量 级 的 Github。 








我 是 在 2010 年 8 月 才 发 现 Gitolite 这 个 项 目的 ， 并 尝试 将 公司 基于 
Gitosis 的 管理 系统 迁移 至 Gitolite。 在 迁移 和 使 用 过 程 中 ， 增 加 和 改进 了 
一 些 实现 ， 如 : 通配符 版 本 库 的 创建 过 程 ， 对 创建 者 的 授权 ， 版 本 库 名 
称 映 射 等 。 本 文 关于 Gitolite 的 介绍 也 是 基于 我 改进 的 版 本 上 。 


` 原作 者 的 版 本 库 地 址 : 


http://github.com/sitaramc/gitolite 


笔者 改进 后 的 Gitolite 分 支 : 
http://github.com/ossxp-com/gitolite 
Gitolite 的 实现 机 制 和 使 用 特点 概 述 如 下 : 


* Gitolite 安 装 在 服务 器 (servet) 的 某 个 账号 之 下 ， 例 如 git 账 号 。 


vw 


理 


1 


通过 git 命 令 检 出 名 为 gitolite-admin 的 版 本 库 。 





$ git clone git@server:gitolite-admin.git 





` 管理 员 将 Git 用 户 的 公 负 保存 在 gitolite-admin 库 的 keydit 目 录 下 ， 并 
编辑 conf/gitolite.conf 文 件 为 用 户 授 权 。 


. 当 管 理 员 提交 对 gitolite-admin 库 的 修改 并 推送 到 服务 器 之 后 ， 服 
务 器 上 gitolite-admin 版 本 库 的 钩子 脚本 将 执行 相应 的 设置 工作 。 


. 新 用 户 的 公 角 自动 追加 到 服务 器 端 安装 账号 主 目录 下 
的 .ssh/authorized_keys 文 件 中 ， 并 设置 该 用 户 的 shell 为 gitolite 的 一 条 命令 


ag-auth-command。 在 .ssh/authorized_keys 文 件 中 增加 的 内 容 示 例如 下 : 





command="/home/git/ .gitolite/src/gl-auth-command 

jiangxin", no-port-forwarding, no-X11-forwarding, no-agent-forwarding, no- 
pty ssh-rsa AAAAB3NzaClyc2...( 公 钥 内 容 来 自 于 jiangxin.pub)...， 

[2 























. 更 新 服务 器 端的 授权 文件 ~/.gitolite/conf/gitolite.conf。 
` 编译 授权 文件 为 ~/.gitolite/conf/gitolite.conf-compiled.pmo。 


若 用 ssh 命 令 登 录 服 务 器 (以 Git 用 户 登 录 ) 时 ， 因 为 公 钥 认证 的 
相关 设置 (使 用 gl-auth-command 作 为 shell) ， 不 能 进入 shell 环 境 ， 而 是 
打印 服务 器 端 Git 库 授权 信息 后 马上 退出 。 即 用 户 不 会 通过 Git 用 户 进 
务 器 的 shell， 也 不 会 对 系统 的 安全 造成 威胁 。 





$ ssh git@bj 
hello jiangxin, the gitolite version here is v1.5.5-9-g4c11bd8 
the gitolite config gives you the following access: 
R gistore-bj.ossxp.com/.*$ 
C R WwW Ossxp/.*$ 
@C @R WwW users/jiangxin/.+$ 
Connection to bj closed. 





* 用 户 可 以 用 git 命 令 访问 授权 的 版 本 库 。 
. 若 管 理 员 授权 ， 用 户 可 以 远程 在 服务 器 上 创建 新 版 本 库 。 


下 面 介 绍 Gitolite 的 部 署 和 使 用 。 在 下 面 的 示例 中 约定 : 服务 器 的 名 
称 为 server，Gitolite 的 安装 账号 为 git， 管 理 员 的 ID 为 admin。 


[1 对 Gitolite 的 各 项 改动 采用 了 Topgit 特 性 分 支 进 行 维护 ， 以 便 与 上 游 的 
最 新 代码 同步 更 新 。 还 要 注意 ， 如 果 使 用 Gitolite ”时 发 现 问题 ， 要 区 分 
是 由 上 游 软 件 引 发 的 ， 还 是 因为 我 的 改动 引起 的 ， 不 要 把 我 的 错误 算 


Sitaram 头 上 。 
DP] 本 段 内 容 为 一 整 行 ， 因 排版 需要 做 了 换行 处 理 。 


30.1 ”安装 Gitolite 


Gitolite 要 求 Git 的 版 本 必须 是 1.6.2 或 以 上 的 版 本 ， 并 且 服 务 器 要 提 
供 SSH 服 务 。 下 面 是 Gitolite 的 安装 过 程 。 


30.1.1 服务 器 端 创建 专用 账号 


安 逆 Gitolite， 首 先 要 在 服务 句 端 创建 专用 账号 ， 所 有 用 户 都 通过 此 
账号 访问 Git 库 。 一 般 为 方便 易 记 ， 选 择 git 作 为 专用 账号 名 称 。 





$ sudo adduser --system --shell /bin/bash --group git 





创建 用 户 git， 并 设置 用 户 的 shell 为 可 登录 的 shell， 如 /bin/bash， 同 
时 添加 同名 的 用 户 组 。 


有 的 系统 ， 只 人 允许 特定 用 户 组 (如 ssh 用 户 组 ) 的 用 户 才 可 以 通过 
SSH 协 议 登 录 ， 这 就 需要 将 新 建 的 git 用 户 同时 也 添加 到 该 特定 的 用 户 组 
中 。 执 行 下 面 的 命令 可 以 将 git 用 户 添加 到 ssh 用 户 组 。 





$ sudo adduser git ssh 





为 git 用 户 设置 口令 。 当 整个 git 服 务 配 置 完成 ， 运 行 正 闻 后 ， 建 议 取 
消 git 的 口令 ， 只 允许 公 钥 认证 。 


$ sudo passwd git 





管理 员 在 客户 端 使 用 下 面 的 命令 ， 建 立 无 口令 登录 : 





$ ssh-copy-id git@server 





人 至此， 已 经 完成 了 安装 git 服 务 的 准备 工作 ， 可 以 开始 安装 Gitolite 服 
务 软件 了 。 


30.1.2 ”Gitolite 的 安装 /升级 [1 


本 布 的 标题 为 安装 /升级 ， 是 因为 Gitolite 的 安装 和 升级 可 以 采用 同 
样 的 步骤 。 





Gitolite 安 装 可 以 在 客户 端 执 行 ， 而 不 需要 在 服务 器 端 操 作 ， 非 常 方 
便 。 远 程 安装 Gitolite 的 前 提 是 


` 已 经 在 服务 器 端 创建 了 专 有 账号 ， 如 8git。 


. 管理 员 能 够 以 git 用 户 的 身份 通过 公 钥 认证 以 无 口令 方式 登录 服务 


安装 和 升级 都 可 以 按照 下 面 的 步 又 进行 


(1) 使 用 git 下 载 Gitolite 的 源 代 码 。 





$ git clone git://github.com/ossxp-com/gitolite.git 





(2) 进入 gitolite/src 目 录 ， 执 行 安装 。 





$ cd gitolite/src 
$ ./gl-easy-install git server admin 





命令 gl-easy-install 的 第 一 个 参数 git 是 服务 器 上 创建 的 专用 账号 ID， 


第 二 个 参数 server 是 服务 器 卫 或 域名 ， 第 三 个 参数 admin 是 管理 员 ID。 








(3) 首先 显示 版 本 信息 。 





you are upgrading (or installing first-time) to vi.5.4-22-g4024621 

Note: getting '(unknown)' for the 'from' version should only happen once. 

Getting '(unknown)' for the 'to' version means you are probably installing 

from a tar file dump, not a real clone. This is not an error but it's nice to 
have those version numbers in case you need support. Try and install from a clone 





(4) 目 动 创建 名 为 admin 的 私 钥 / 公 钥 对 。 创 建 的 公 钥 / 私 钥 对 的 名 


称 来 自 于 gl-easy-install 命 令 的 最 后 一 个 参数 admin。 





the next command will create a new keypair for your gitolite access 
The pubkey will be /home/jiangxin/.ssh/admin.pub. You will have to choose a 
passphrase or hit enter for none. I recommend not having a passphrase for 
now, *especially* if you do not have a passphrase for the key which you are 
already using to get server access! 
Add one using 'ssh-keygen -p' after all the setup is done and you've 
successfully cloned and pushed the gitolite-admin repo. After that, install 
'keychain' or something similar, and add the following command to your bashrc 
(since this is a non-default key) 

ssh-add $HOME/.ssh/admin 
This makes using passphrases very convenient. 





《5) 如 果 公 和 钥 已 经 存在 ， 会 弹出 警告 。 


Hmmm,... pubkey /home/jiangxin/.ssh/admin.pub exists; should I just (re-)use it? 
IMPORTANT: once the install completes, *this* key can no longer be used to get 
a command line on the server -- it will be used by gitolite, for git access 
only. If that is a problem, please ABORT now， 

doc/6-ssh-troubleshooting.mkd will explain what is happening here, if you need 
more info. 








(6) 目 动 修改 客户 端的 .ssh/config 文 件 ， 增 加 名 为 gitolite 的 别名 主 
机 。 


即 当 访问 主机 gitolite 时 ， 会 自动 用 名 为 admin.pub 的 公 钥 ， 以 git 用 户 
的 身份 连接 服务 器 。 





creating settings for your gitolite access in /home/jiangxin/.ssh/config; 
these are the lines that will be appended to your ~/.ssh/config: 
host gitolite 

user git 

hostname server 

port 22 

identityfile ~/.ssh/admin 





(7) 上 传 脚本 文件 到 服务 器 ， 完 成 服务 器 端 软件 的 安 疼 。 





gl-dont-panic 


100% 3106 3.0KB/s 00:00 
gl-conf-convert 

100% 2325 2.3KB/s 00:00 
gl-setup-authkeys 

100% 1572 1.5KB/s 00:00 


gitolite-hooked 


100% 0 0.0KB/s 00:00 
update 
100% 4922 4.8KB/s 00:00 


the gitolite rc file needs to be edited by hand. The defaults are sensible, 
so if you wish, you can just exit the editor. 

Otherwise, make any changes you wish and save it. Read the comments to 
understand what is what -- the rc file's documentation is inline. 

Please remember this file will actually be copied to the server, and that all 
the paths etc. represent paths on the server! 


一 一 | 


(8) 自动 调用 vi 编辑 器 打开 .gitolite.rc 文 件 ， 编 辑 结束 后 上 传 到 服 
务 器 。 

该 配置 文件 为 Perl 语 法 ， 注 意 保 持 文 件 格 式 和 语法 。 退 出 vi 编辑 
器 ， 输 入 “<ESC>:q9”( 不 齐 引 号 ) 。 以 下 为 该 配置 文件 中 比较 重要 的 设 
置 ， 一 般 无 须 改 变 默 认 的 配置 。 


* $FREPO_BASE="repositories"; 


用 于 设置 Git 服 务 器 的 根 目录 ， 默 认 是 Git 用 户主 目录 下 的 
repositories 目 录 ， 可 以 使 用 绝对 路 径 。 所 有 Git 库 都 将 部 署 在 该 目录 下 。 





* $BREPO_UMASK=0007;# gets you TWXTWX--- 





版 本 库 创建 使 用 的 掩 码 。 即 新 建立 的 版 本 库 的 权限 为 TWXrwx---'。 


“ $GL_BIG_CONFIG=0; 


如 果 授 权 文 件 非常 复杂 ， 更 改 此 项 配置 为 1， 以 免 产 生 庞大 的 授权 
编译 文件 。 


* $GL_WILDREPOS=1; 


默认 文 持 通配符 版 本 库 授权 。 


(9) 至 此 完成 安装 。 


30.1.3 ”关于 SSH 主 机 别名 





在 安装 过 程 中 ，gitolite 创 建 了 名 为 admin 的 公 钥 / 私 钥 对 ， 以 名 为 
admin.pub 的 公 钥 连接 服务 器 的 git 账 户 ， 使 用 由 gitolite 提 供 的 Git 服 务 。 
但 是 如 果 直 接连 接 服务 器 ， 使 用 的 是 默认 的 公 钥 ， 会 直接 进入 shell。 








那么 如 何 能 够 根据 需要 选择 不 同 的 公 钥 来 连接 git 服 务 器 呢 ? 


别 筷 了 在 前 面 介绍 过 的 SSH 主 机 别名 。 实 际 上 刚刚 在 安装 gitolite 的 
时 候 ， 就 已 经 自动 地 创建 了 一 个 主机 别名 。 打 开 ~/.ssh/config 文 件 可 以 看 
到 类 似 内 容 ， 如 果 对 主机 别名 不 满意 可 以 修改 。 





host gitolite 
user git 
hostname server 
port 22 
identityfile ~/.ssh/admin 





Rh : 


` 像 下 面 这 样 输入 SSH 命 令 会 直接 进入 shell， 因 为 使 用 的 是 默认 的 
公 铀 。 





$ ssh git@server 





` 像 下 面 这 样 输入 SSH 命 令 则 不 会 进入 shell。 因 为 使 用 名 为 
admin.pub 的 公 钥 ， 会 显示 Git 授 权 信 息 并 马上 退出 。 





$ ssh gitolite 





30.14， 上 其 他 的 安装 方法 


上 面 介 绍 的 是 在 客户 端 远程 安装 Gitolite， 是 最 常用 和 推荐 的 方法 。 
当然 还 可 以 直接 在 服务 器 上 安装 ， 共 体操 作 过 程 如 下 。 





(1) 首先 也 要 在 服务 器 疹 先 创建 一 个 专用 的 账号 ， 如 git。 





$ sudo adduser --system --shell /bin/bash --group git 





(2) 将 管理 员 公 钥 复 制 到 服务 器 上 。 


管理 员 在 客户 端 执行 下 面 的 命令 : 





$ scp ~/.ssh/id_rsa.pub server:/tmp/admin.pub 





(3) 服务 器 端 安装 Gitolite〈 源 码 方式 安装 ) 。 


推荐 采用 源码 方式 安装 ， 因 为 如 果 以 平台 目 带 软件 包 模 式 安 装 
Gitolite， 那 么 其 中 就 不 包含 我 对 Gitolite 的 改进 。 


` 使 用 git 下 载 Gitolite 的 源 代码 。 





$ git clone git://github.com/ossxp-com/gitolite.git 





创建 目录 。 





$ sudo mkdir -p /usr/local/share/gitolite/conf \ 
/usr/local/share/gitolite/hooks 





进入 gitolite/src 目 录 ， 执 行 安 装 。 





$ cd gitolite/src 

$ sudo ./gl-system-install /usr/local/bin \ 
/usr/local/share/gitolite/conf\ 
/usr/local/share/gitolite/hooks 





安装 完毕 跳 到 步骤 5。 


(4) 服务 器 端 安装 Gitolite 〈 平 台 包 管理 器 安装 ) 。 


如 果 不 选 择 从 源 代 码 进 行 安装 〈 如 步骤 3) ， 也 可 以 使 用 当前 平台 
的 包 管理 器 进行 安装 。 例 如 在 Debian/Ubuntu 平 台 执行 下 面 的 命令 





$ sudo aptitude install gitolite 








(5) 在 服务 器 端 以 专用 账号 执行 安装 脚本 。 


例如 服务 器 端的 专用 账号 为 git， 先 执行 su 命令 ， 临 时 切换 到 该 用 
户 ， 继 续 下 面 的 安装 。 





$ sudo Su - git 
$ gl-setup /tmp/admin.pub 





(6) 管理 员 在 客户 端 元 隆 gitolite-admin 库 。 





$ git clone git@server:gitolite-admin 





(7) 在 克隆 出 来 的 gitolite-admin 工 作 区 中 ， 以 Git 的 方式 管理 
gitolite。 如 添加 、 删 除 用 户 账 号 ,设置 用 户 权 限 。 





升级 Gitolite 只 需要 执行 上 面 的 步骤 3 或 步骤 4 即 可 完成 升级 。 如 果 还 
修改 或 增加 了 新 的 钩子 脚本 ， 还 需要 重新 执行 步骤 5。Gitolite 的 升级 有 
可 能 要 求 修改 配置 文件 : ~/.gitolite.rc。 


[1] 安装 和 使 用 2.1 或 更 新 版 本 的 Gitolite 请 跳 转 到 第 30.1.4 小 节 。 本 节 介 绍 
的 从 客户 端 发 起 安装 虽然 很 酷 ， 而 且 是 Gitolite 的 主要 安装 方式 ， 但 管理 
员 要 维护 两 套 不 同 的 公 钥 ， 这 让 技术 支持 不 堪 重 负 ， 最 终 官方 在 2.1 版 中 
取消 了 这 种 安装 的 方式 。 详 见 我 的 博客 : 

http:/ /www.wotldhello.net/2011/30/02-gitolite-install.html。 


30.2 ”管理 Gitolite 


30.2.1 ”管理 员 元 隆 gitolite-admin 管 理 库 


当 Gitolite 安 装 完成 后 ， 在 服务 器 端 自动 创建 了 一 个 用 于 Gitolite 自 身 
管理 的 Git 库 : gitolite-admin.git。 


克隆 gitolite-admin.git 库 。 别 忘 了 使 用 SSH 主 机 别名 : 





$ git clone gitolite:gitolite-admin.git 
Initialized empty Git repository in /data/tmp/gitolite-admin/ .git/ 
remote: Counting objects: 6, done. 

remote: Compressing objects: 100% (4/4), done. 
remote: Total 6 (delta 0), reused 0 (delta 0) 
Receiving objects: 100% (6/6), done. 

$ cd gitolite-admin/ 

$ ls -F 

conf/ keydir/ 

$ ls conf 

gitolite.conf 

$ ls keydir/ 

admin.pub 








可 以 看 出 gitolite-admin 目 录 下 有 两 个 目录 conf/ 和 keydir/。 
“ keydit/admin.pub 文 件 
目录 keydir 下 初始 时 只 有 一 个 用 户 公 钥 ， 即 amdin 用 户 的 公 包 。 


conf/gitolite.conf 文 件 


该 文件 为 授权 文件 。 初 始 内 容 为 : 





#gitolite conf 
# please see conf/example.conf for details on syntax and features 
repo gitolite-admin 


RW+ = admin 
repo testing 
RW+ = @all 





默认 授权 文件 中 只 设置 了 两 个 版 本 库 的 授权 : 
* gitolite-admin 


即 本 版 本 库 (gitolite 管 理 版 本 库 ) 中 只 有 admin 用 户 有 读 写 和 强制 
更 新 的 权限 。 


* testing 


默认 设置 的 测试 版 本 库 ， 设 置 为 任何 人 都 可 以 读 写 及 强制 更 新 。 


30.2.2 ”增加 新 用 户 


增加 新 用 户 ， 就 是 允许 新 用 户 能 够 通过 其 公 钥 访问 Git 服 务 。 只 要 
将 新 用 户 的 公 钥 添加 到 gitolite-admin 版 本 库 的 keydir 目 录 下 ， 即 完成 新 
用 户 的 添加 ， 具 体操 作 过 程 如 下 。 


(1) 管理 员 从 用 户 获 取 公 钥 ， 并 将 公 和 钥 按 照 username.pub 格 式 进行 
重 命名 。 


* 用 户 可 以 通过 邮件 或 其 他 方式 将 公 铀 传递 给 管理 员 ， 切 记 不 要 将 
私 钥 误 传 给 管理 员 。 如 果 发 生 私 钥 泄 漏 ， 马 上 重新 生成 新 的 公 钥 / 私 铀 
对 ， 并 将 新 的 公 铀 传递 给 管理 员 ， 并 申请 将 旧 的 公 钥 作废 。 


- 用 户 从 不 同 的 客户 端 主机 访问 有 着 不 同 的 公 钥 ， 如 果 和 希望 使 用 同 
一 个 用 户 名 进行 授权 ， 可 以 按照 username(@host.pub 的 方式 命名 公 和 钥 文 
件 ， 和 名 为 username.pub 的 公 角 指向 同一 个 用 户 username。 


Gitolite 也 支持 邮件 地 址 格式 的 公 钥 ， 即 形 如 
username(@email.com.pub 的 公 和 钥 。Gitolite 能 够 很 智能 地 区 分 是 以 邮件 地 
址 命名 的 公 钥 还 是 相同 用 户 在 不 同 主机 上 的 公 钥 。 如 果 是 邮件 地 址 命 
的 公 钥 ， 将 以 整个 邮件 地 址 作为 用 户 名 。 


(2) 管理 员 进 入 gitolite-admin 本 地 克隆 版 本 库 中 ， 复 制 新 用 户 公 乌 
到 keydir 目 录 。 





$ cp /path/to/devi.pub keydir/ 
$ cp /path/to/dev2.pub keydir/ 
$ cp /path/to/jiangxin.pub keydir/ 





(3) 执行 git add 命 令 ， 将 公 钥 添加 到 版 本 库 。 





$ git add keydir 

$ git status 

# On branch master 

# Changes to be committed: 


# (use "git reset HEAD <file>..." to unstage) 
## 

# new file: keydir/devi.pub 

# new file: keydir/dev2.pub 

# new file: keydir/jiangxin.pub 





(4) 执行 git commit， 完 成 提交 。 





$ git commit -m "add user: jiangxin, dev1， dev2" 
[master bd81884] add user: jiangxin, dev1， dev2 
3 files changed, 3 insertions(+), 0 deletions(-) 
create mode 100644 keydir/devi.pub 
create mode 100644 keydir/dev2.pub 
create mode 100644 keydir/jiangxin.pub 








(5) 执行 git push， 同 步 到 服务 器 ， 才 真正 完成 新 用 户 的 添加 。 





$ git push 

Counting objects: 8, done. 

Delta compression using up to 2 threads. 
Compressing objects: 100% (6/6), done. 
Writing objects: 100% (6/6), 1.38 KiB, done. 
Total 6 (delta 0), reused 0 (delta 0) 

remote: Already on 'master' 


remote: 
remote: ***** WARNING ***** 
remote: the following users (pubkey files in parens) do not appear 


in the config file: 
remote: devi(devi.pub), dev2(dev2.pub), jiangxin(jiangxin.pub) 





如 果 这 时 查看 服务 器 端 git 用 户主 目录 下 的 .ssh/authorized_keys 文 
件 ， 会 发 现 新 增 的 用 户 公 钥 也 附加 在 其 中 : 





$ cat ~git/,ssh/authorized_keys 

# gitolite start 

command="/home/git/.gitolite/src/gl-auth-command 

admin", no-port-forwarding, no-X11-forwarding, no-agent-forwarding, no-pty < 用 户 
admin 的 公 钥 ,, ,> 
command="/home/git/.gitolite/src/gl-auth-command 
dev1", no-port-forwarding, no-X11-forwarding, no-agent-forwarding, no-pty < 用 户 
dev1 的 公 钥 .. .> 

command="/home/git/ .gitolite/src/gl-auth-command 
dev2", no-port-forwarding, no-X11-forwarding, no-agent-forwarding, no-pty < 用 户 
dev2 的 公 钥 .. .> 

command="/home/git/ .gitolite/src/gl-auth-command 
jiangxin", no-port-forwarding, no-X11-forwarding, no-agent-forwarding,， no-pty < 用 户 
jiangxin 的 公 钥 .. .> 

# gitolite end 




















在 之 前 执行 git push 后 的 输出 中 ， 以 remote 标 识 的 输出 是 服务 需 端 执 
行 post-update 钩 子 脚本 的 输出 。 其 中 的 警告 是 次 新 添加 的 三 个 用 户 在 授 
权 文 件 中 没有 被 引用 。 接 下 来 便 看 看 如 何 修改 授权 文件 ， 以 及 如 何 为 用 
户 添 加 授权 。 





30.2.3 ”更 改 授权 


新 用 户 添加 完毕 ， 可 能 需要 重新 进行 授权 。 更 改 授权 的 方法 也 非常 
简单 ， 即 修改 conf/gitolite.conf 配 置 文件 ， 提 交 并 推送 ， 有 具体 操作 过 程 如 
下 





(1) 管理 员 进 入 gitolite-admin 本 地 克隆 版 本 库 中 ， 编 辑 


conf/gitolite.conf。 





$ vi conf/gitolite.conf 


(2) 授权 指令 比较 复杂 ， 先 通过 建立 新 用 户 组 尝试 一 下 更 改 授 权 
文件 。 





考虑 到 之 前 增加 了 三 个 用 户 公 钥 ， 服 务 嚣 端 发 出 了 用 户 尚 未 在 授权 
文件 中 出 现 的 警告 。 现 在 就 在 这 个 示例 中 解决 这 个 问题 。 


. 可 以 在 其 中 加 入 用 户 组 @team1， 将 新 添加 的 用 户 jiangxin、dev1、 


dev2 都 归属 到 这 个 组 中 。 只 需要 在 conf/gitolite.conf 文 件 的 文件 头 加 入 如 


下 指令 即 可 。 用 户 名 之 间 用 空格 分 隔 。 





Q@team1 = dev1 dev2 jiangxin 





. 还 修改 了 版 本 库 testing 的 授权 ， 将 @all 用 户 组 改 为 新 建立 的 
team1 用 户 组 。 从 编辑 完毕 后 的 文件 差异 输出 可 以 看 到 相关 改动 。 





$ git diff 

diff --git a/conf/gitolite.conf b/conf/gitolite.conf 

index 6c5fdf8..f983a84 100644 

--- a/conf/gitolite.conf 

+++ b/conf/gitolite.conf 

QQ -1, 10 +1, 12 @@ 

#gitolite conf 

# please see conf/example.conf for details on syntax and features 
+@team1 = devi dev2 jiangxin 


十 
repo gitolite-admin 
RW+ = admin 
repo testing 
RW+ = @all 
+ RW+ = @team1 








(3) 编辑 结束 ， 提 区 改动 。 





$ git add conf/gitolite.conf 
$ git commit -q -m "new team @team1 auth for repo testing." 





(4) 执行 git push， 同 步 到 服务 器 ， 授 权 文 件 的 更 改 才 真正 生效 。 


可 以 注意 到 ， 推 送 后 的 输出 中 没有 了 警告 。 








$ git push 

Counting objects: 7, done. 

Delta compression using up to 2 threads. 
Compressing objects: 100% (3/3), done. 


Writing objects: 100% (4/4), 398 bytes, done. 

Total 4 (delta 1), reused 0 (delta 0) 

remote: Already on 'master' 

To gitadmin.bj:gitolite-admin.git 
bd81884..79b29e4 master -> master 


二 一 


30.3 ”Gitolite 授 权 详 解 


30.3.1 授权 文件 的 基本 语法 


下 面 看 一 个 不 那么 简单 的 授权 文件 。 为 方便 描述 添加 了 行 号 。 





1 Qadmin = jiangxin wangsheng 

尼 

3 repo gitolite-admin 

4 RW+ = jiangxin 

5 

6 repo ossxp/.+ 

7 C = @admin 

8 RW = @al1 

9 

10 repo testing 

11 RW+ = Q@admin 
12 RW master = junio 
13 RW+ pu = junio 
14 RW cogitos$ = pasky 
15 RW bw/ = linus 
16 - = somebody 
17 RW tmp/ = @all 
18 RW refs/tags/v[0-9] = junio 








在 上 面 的 示例 中 ， 演 示 了 很 多 授权 指令 : 


` 第 1 行 ， 定 义 了 用 户 组 Q@admin， 包 含 两 个 用 户 jiangxin 和 


wangsheng。 


` 第 3~4 行 ， 定 义 了 版 本 库 gitolite-admin。 并 指定 只 有 用 户 jiangxin 才 
能 够 访问 ， 并 拥有 读 (R) 写 (W) 和 强制 更 新 〈+) 的 权限 。 


` 第 6 行 ， 通 过 正则 表达 式 定义 了 一 组 版 本 库 ， 即 在 ossxp/ 目 录 下 的 


所 有 版 本 库 。 


第 7 行 ， 用 户 组 (@admin 中 的 用 户 ， 可 以 在 ossxp/ 目 录 下 创建 版 本 
库 。 创 建 版 本 库 的 用 户 ， 具 有 对 版 本 库 操 作 的 所 有 权限 。 


第 8 行 ， 所 有 用 户 都 可 以 读 写 ossxp 目 录 下 的 版 本 库 ， 但 不 能 强制 
更 新 。 


第 10 行 开始 ， 定 义 的 testing 版 本 库 授 权 使 用 了 引用 授权 语法 。 


. 第 11 行 ， 用 户 组 @admin 对 所 有 的 分 支 和 里 程 碑 拥有 读 写 、 重 
置 、 添 加 和 删除 的 授权 。 


` 第 12 行 ， 用 户 junio 可 以 读 写 master 分 支 。 (还 包括 名 字 以 master 开 
头 的 其 他 分 支 ， 如 果 有 的 话 。) 


` 第 13 行 ， 用 户 junio 可 以 读 写 、 强 制 更 新 、 创 建 及 删除 pu 开头 的 分 


“第 14 行 ， 用 户 pasky 可 以 读 写 cogito 分 支 。( 仅 此 分 支 ， 精 确 匹 


30.3.2 ”定义 用 户 组 和 版 本 库 组 


在 conf/gitolite.conf 授 权 文 件 中 ， 可 以 定义 用 户 组 或 版 本 库 组 。 组 名 





称 以 @ 字 符 开 头 ， 可 以 包含 一 个 或 多 个 成 员 。 成 员 之 间 用 空格 分 开 。 


. 例如 定义 管理 员 组 : 





@admin = jiangxin wangsheng 





. 组 可 以 识 套 : 





@staff = @admin @engineers tester1 





` 除了 作为 用 户 组 外 ， 同 样 的 语法 也 适用 于 版 本 库 组 。 





版 本 库 组 和 用 户 组 的 定义 没有 任何 区 别 ， 只 是 在 版 本 库 授权 指令 中 
处 于 不 同 的 位 置 。 即 位 于 授权 指令 中 的 版 本 库 位 置 代表 版 本 库 组 ， 位 于 
授权 指令 中 的 用 户 位 置 代 表 用 户 组 。 


30.3.3 ”版 本 库 ACL 








一 个 版 本 库 可 以 包含 多 条 授权 指令 ， 这 些 授权 指令 组 成 了 一 个 版 本 
库 的 权限 控制 列表 (ACL)〉。 例 如 : 





repo testing 
RW+ = jiangxin @admin 
RW = @dev @test 
R = @all 





1. 版 本 库 


每 一 个 版 本 库 授 权 都 以 一 条 repo 指 令 开始 。 


指令 tepo 后 面 是 版 本 库 列 表 ， 版 本 之 间 用 空格 分 开 ， 还 可 以 包括 
版 本 库 组 。 





注意 : 版 本 库 名 称 不 要 添加 .git 后 级 。 在 版 本 库 创建 过 程 中 会 自动 
添加 .git 后 级 。 





repo sandbox/test1 sandbox/test2 @test_repos 





. 用 repo 指 令 设 置 的 版 本 库 会 自动 在 服务 器 上 创建 ， 但 是 如 果 repo 
指令 后 面 的 版 本 库 名 称 中 包含 通配符 ， 则 不 会 自动 创建 。 


. frepo 指 令 后 面 的 版 本 库 名 称 中 可 以 使 用 正则 表达 式 ， 这 种 用 正则 
表达 式 定义 的 版 本 库 称 为 通配符 版 本 库 。 


在 Gitolite 对 用 户 访 问 版 本 库 名 称 进 行 匹 配 时 ， 会 自动 给 看 似 通 配 符 
版 本 库 的 名 称 加 上 前 绥 A^ 和 后 绥 $。 这 一 点 和 后 面 将 要 介绍 的 正则 引用 
Crefex) 大 不 一 样 。 








repo ossxp/.+ 





不 过 有 时 候 使 用 了 过 于 简单 的 正则 表达 式 ， 如 “myrepo.”， 有 可 能 会 
产生 歧义 ， 让 Gitolite 将 希望 用 正则 表达 式 表示 的 通配符 版 本 库 误 判 为 普 
通 版 本 库 名 称 ， 在 服务 器 端 自 动 创建 名 为 myrepo..git 的 版 本 库 。 解 决 疏 








义 的 一 个 办 法 是 : 在 正则 表达 式 的 前 面 明 确 地 插入 ^ 符 号 ， 或 者 在 表达 
式 后 面 添加 $ 符 号 ， 形 如 : “Amyrepo.”、“myrepo.$”， 或 “Amyrepo.$”。 


2 人 和 





在 repo 指 令 之 后 是 缩 进 的 一 条 或 多 条 授权 指令 。 授 权 指 令 的 语法 如 
下 




















< 权限 > ”[ 零 个 或 多 个 正则 表达 式 匹 配 的 引用 ] = <user> [<user> ...] 











. 每 条 指令 必须 指定 一 个 权限 。 权 限 可 以 用 下 面 任意 一 个 权限 关键 


地 





C、R、RW、RW+、RWC、RW+C、RWD、RW+D、RWCD、RW+CD 。 





. 权限 后 面包 含 一 个 可 选 的 正则 引用 (refex) 列表 。 


正则 表达 式 格式 的 引用 ， 简 称 正则 引用 (refex〉， 对 Git 版 本 库 的 
引用 《分 文 、 里 程 碑 等 ) 进行 匹配 。 


如 傈 在 授权 指令 中 省 略 正 则 引用 ， 则 意味 独 对 全 部 的 Git 引 用 《分 
文 、 里 程 碑 等 ) 都 有 效 。 





正则 引用 如 果 不 以 refs/ 开 涉 ， 会 自动 添加 refs/heads/ 作 为 前 级 。 





正则 引用 如 果 不 以 $ 结 尾 ， 则 意味 着 后 面 可 以 匹配 任意 人 字符， 相当 


于 添加 .*$ 作 为 后 级 。 


` 权限 后 面 也 可 以 包含 一 个 以 NAME/ 为 前 级 的 路 径 列 表 ， 进 行 基 


于 路 径 的 授权 。 


` 授权 指令 以 等 号 (=) 为 标记 分 为 前 后 两 段 ， 等 号 后 面 的 是 用 户 
列表 。 用 户 之 间 用 空格 分 隔 ， 并 且 可 以 使 用 用 户 组 。 


3. 授 权 关 键 字 





不 同 的 授权 关键 字 有 不 同 的 含义 ， 有 的 授权 关键 字 只 用 在 特定 的 场 


人 
口 o 


C 代 表 创 建 。 仪 在 通配符 版 本 库 授权 时 可 以 使 用 。 用 于 指定 谁 可 以 
创建 与 通配符 匹配 的 版 本 库 。 


. R、RW 和 RW7+ 








R 为 只 读 。RW 为 读 写 权限 。RW+ 含 义 为 除了 上 共有 读 写 权限 外 ， 还 
可 以 强制 执行 非 快 进 式 推送 。 


“ RWC、~ RW+C 


只 有 当 授 权 指令 中 定义 了 正则 引用 《正则 表达 式 定 义 的 分 支 、 里 程 





碑 等 ) 时 ， 才 可 以 使 用 该 授权 指令 。 其 中 C 的 含义 是 允许 创建 和 正则 表 
达 式 匹配 的 引用 (分支 或 里 程 碑 等 )。 加 号 (+) 的 含义 是 允许 强制 推 
送 。 


RWD 、 RW+D 





只 有 当 授 权 指 令 中 定义 了 正则 引用 《正则 表达 式 定义 的 分 文 、 里 程 
碑 等 ) 时 ， 才 可 以 使 用 该 授权 指令 。 其 中 D 的 含义 是 允许 删除 和 正则 表 
达 式 匹配 的 引用 《分 文 或 里 程 碑 等 ) ， 加 号 〈+) 的 含义 是 允许 强制 推 
1 


“ RWCD、 RW+CD 


只 有 妆 授 权 指 令 中 定义 了 正则 引用 (正则 表达 式 定 义 的 分 支 、 里 程 
碑 等 ) 时 ， 才 可 以 使 用 该 授权 指令 。 其 中 C 的 含义 是 允许 创建 和 正则 表 
达 式 匹配 的 引用 (分支 或 里 程 碑 等) ，D 的 含义 是 允许 删除 和 正则 表达 
式 匹 配 的 引用 《分 文 或 里 程 碑 等 ) ， 加 号 〈+) 的 含义 是 允许 强制 推 
运 ， 





30.3.4 ”Gitolite 授 权 机 制 


Gitolite 的 授权 实际 分 为 两 个 阶段 ， 第 一 个 阶段 称 为 前 Git 阶 段 ， 即 
在 Git 命 令 执 行 前 ， 由 SSH 连 接触 发 的 gl-auth-command 命 令 执 行 的 授权 


检查 。 包 括 : 


` 版 本 库 的 读 。 


如 果 用 户 拥有 版 本 库 〈 或 至 少 一 个 分 支 ) 的 下 列 权限 之 一 : R、 
RW 或 RW+， 则 整个 版 本 库 ( 包 含 所 有 分 支 ) 对 用 户 均 可 读 。 








实际 上 为 用 户 设置 东 个 分 文 的 R 权 限 的 含义 并 非 其 他 分 文 不 可 读 ， 
而 是 此 分 支 不 可 写 。 之 所 以 Gitolite 对 读 授 权 不 能 细 化 到 分 支 甚 至 目录 ， 
只 能 粗放 地 对 整个 版 本 库 进 行 读 授 权 ， 是 因为 读 授 权 只 在 版 本 库 授权 的 
第 一 个 阶段 进行 检查 ， 而 在 此 阶段 还 获取 不 到 版 本 库 的 分 支 。 


` 版 本 库 的 写 


版 本 库 的 写 授权 实际 上 要 在 两 个 阶段 分 别 进行 检查 。 第 一 阶段 仅 检 
查 用 户 是 否 拥有 下 列 权限 之 一 : RW、RW+ 或 C 授 权 ， 具 有 这 些 授权 则 
通过 第 一 阶段 的 写 权 限 检 查 。 人 至 于 要 在 第 二 个 阶段 进行 基于 分 文 和 路 径 
的 写 操作 授权 ， 以 及 对 分 支 创 建 、 删 除 和 是 人 否 可 强制 更 新 进行 判断 ， 则 
参见 后 面 对 第 二 阶段 授权 过 程 的 描述 











` 版 本 库 的 创建 。 


仅 对 正则 表达 式 定义 的 通配符 版 本 库 有 效 。 即 拥有 C 授 权 的 用 户 可 
以 创建 和 对 应 正则 表达 式 匹配 的 版 本 库 。 同 时 该 用 户 也 拥有 对 版 本 库 的 
读 写 权限 。 


Gitolite 对 授权 的 第 二 个 阶段 的 检查 ， 实 际 上 是 通过 update 钓 子 脚本 
进行 的 % 


. 因为 版 本 库 的 读 操作 不 执行 Wpdate 钓 子 ， 所 以 读 操 作 只 在 授权 的 
第 一 个 阶段 (前 Git 阶 段 ) 就 完成 了 检查 ， 授 权 的 第 二 个 阶段 对 版 本 库 
的 读 授 权 无 任何 影响 。 


. 钩子 脚本 update 针 对 推送 操作 的 各 个 分 支 进行 逐一 检查 ， 因 此 第 
二 个 阶段 可 以 进行 针对 分 支 写 操作 的 精细 授权 。 


` 在 这 个 阶段 可 以 获取 到 要 更 新 的 新 、 老 引用 的 SHA1 哈 希 值 ， 因 
此 可 以 判断 出 是 否 发 生 了 非 快 进 式 推 送 、 是 否 有 新 分 支 创 建 ， 以 及 是 否 
发 生 了 分 支 的 删除 ， 因 此 可 以 针对 这 些 操作 进行 精细 的 授权 。 


. 基于 路 径 的 写 授权 也 是 在 这 个 阶段 进行 的 。 


30.4 ”版 本 库 授 权 肥 例 








Gitolite 的 授权 非常 强大 也 非常 复 茶 ， 因 此 从 版 本 库 授 权 的 实际 采 例 
来 学 习 是 非常 有 效 的 方式 。 














30.4.1 对 整个 版 本 库 进 行 授 权 


授权 文件 如 下 : 





@admin = jiangxin 
@dev = devi1 dev2 badboy jiangxin 
@test = test1 test2 


R = @test 
- = badboy 
RW = @dev test1 


1 
2 
3 
4 
5 repo testing 
6 
7 
8 
9 RW+ = @admin 





说 明 : 
* 用 户 test1 对 版 本 库 具 有 写 的 权限 。 


第 6 行 定义 了 test1 所 属 的 用 户 组 @test 具 有 只 读 权 限 。 第 8 行 定义 了 
test1 用 户 具 有 读 写 权限 。Gitolite 的 实现 是 对 读 权 限 和 写 权 限 分 别 进行 判 
灯 并 汇总 〈 并 集 ) ， 从 而 test1 用 户 具 有 读 写 权限 。 

















* 用 户 jiangxin 对 版 本 库 具 有 写 的 权限 ， 并 能 够 强制 推送 。 


第 9 行 授 权 指 令 中 加 号 〈+) 的 含义 是 允许 强制 推送 。 


森 用 指令 ， 让 用 户 badboy 只 对 版 本 库 具 有 读 操 作 的 权限 。 





第 7 行 的 指令 以 减 号 〈-) 开始 ， 是 一 条 禁用 指令 。 禁 用 指令 只 在 授 
权 的 第 二 阶段 起 作用 ， 即 只 对 写 操作 起 作用 ， 不 会 对 badboy 用 户 的 读 权 
限 施加 影响 。 





在 第 8 行 的 指令 中 ，badboy 所 在 的 @dev 组 拥有 读 写 权限 。 但 禁用 规 
则 会 对 写 操 作 起 作用 ， 导 致 badboy 只 有 读 操 作 权 限 ， 而 没有 写 操作 。 


30.4.2 ”通配符 版 本 库 的 授权 


返 仅 区 人 下 





@administrators = jiangxin admin 
@dev = dev1 dev2 badboy 
@test = test1 test2 


repo sandbox/.+$ 
C = @administrators 
R = @test 


‘ONOOORODP 


badboy 
RW = @dev test1 





这 个 授权 文件 的 版 本 库 名 称 中 使 用 了 正则 表达 陈 ， 匹 配 在 sandbox 
下 的 任意 版 本 库 。 





正则 表达 式 来 尾 的 4$ 有 着 特殊 的 含义 ， 代 表 匹 配 字 符 串 的 结尾 ， 明 
确 告诉 Gitolite 这 个 版 本 库 是 通配符 版 本 库 。 因 为 加 号 + 既 可 以 作为 普通 


字符 出 现在 版 本 库 的 命名 中 ， 又 可 以 作为 正则 表达 式 中 特殊 含义 的 字 
符 ， 如 果 Gitolite 将 授权 文件 中 的 通配符 版 本 库 误 判 为 普通 版 本 库 ， 就 会 
目 动 在 服务 器 并 创建 该 版 本 库 ， 这 可 不 是 管理 员 和 希望 发 生 的 。 





我 修改 了 Gitolite 的 代码 ， 能 正确 判断 部 分 正则 表达 式 ， 但 是 最 好 还 
古 对 简单 的 正则 表达 式 添加 人 作为 前 级 或 $ 作 为 后 级 ， 以 避免 误 判 。 


正则 表达 式 定 义 的 通配符 版 本 库 不 会 目 动 创 建 ， 需 要 管理 员 手 动 创 
建 。 





Gitolite 原 来 对 通配符 版 本 库 的 实现 是 殉 隆 即 创建 ， 但 是 这 样 很 容易 
因为 录入 错误 而 导致 错误 的 版 本 库 被 意外 创建 。 我 改进 的 Gitolite 需 要 通 
过 推送 来 创建 版 本 库 。 











下 面 的 示例 通过 推送 操作 〈 以 admin 用 户 身 份 ) ， 远 程 创 建 版 本 库 


Sandbox/repos1.git。 


$ git push gitolite 
[2] 


:sandbox/reposi.git master 
创建 完毕 后 对 各 个 用 户 的 权限 进行 测试 会 及 现 : 


用 户 admin 对 版 本 库 具 有 写 的 权限 。 


这 并 不 是 因为 第 6 行 的 授权 指令 为 @administrators 授 予 了 C 的 权限 。 
而 是 因为 该 版 本 库 是 由 admin 用 户 创建 的 ， 创 建 者 具有 对 版 本 库 完 全 的 
读 写 权限 。 











服务 器 端 该 版 本 库 目 录 上 自动 生成 的 gl-creator 文 件 记 录 了 创建 者 的 ID 
为 admin 。 
` 用 户 jiangxin 对 版 本 库 没有 读 写 权 限 。 


虽然 用 户 jiangxin 和 用 户 admin 一 样 都 可 以 在 sandbox/ 下 创建 版 本 
库 ， 但 是 由 于 sandbox/repos1.git 己 经 存在 并 且 不 是 jiangxin 用 户 创建 的 ， 
所 以 jiangxin 用 户 没 有 任何 权限 ， 不 能 读 写 。 








和 之 前 的 例子 相同 的 是 : 
"用户 test1 对 版 本 库 具有 写 的 权限 。 
禁用 指令 让 用 户 badboy 对 版 本 库 只 有 具有 读 操作 的 权限 。 
. 版 本 库 的 创建 者 还 可 以 使 用 setperms 命 令 为 版 本 库 添加 授权 。 具 
体 用 法 参见 下 面 的 示例 。 


30.4.3 ”用 户 自己 的 版 本 库 空间 


授权 文件 如 下 : 





1 @administrators = jiangxin admin 
2 


3 repo users/CREATOR/.+$ 
4 C = @all 
5 R = @administrators 





说 明 : 
. 第 5 条 指令 ， 设 置 管 理 员 组 对 任何 用 户 在 users/ 目 录 下 创建 的 版 本 


库 都 有 只 读 权 限 。 


. 第 4 条 指令 ， 设 置 用户 可 以 在 自己 的 名 字 空 间 (/usts//) 下 ， 自 
己 创建 版 本 库 。 例 如 下 面 就 是 用 户 dev1 在 服务 器 端 自己 的 名 字 空 间 下 创 
建 版 本 库 。 





$ git push devi-server 


:UsSers/devi/repos1.git master 





. 用 户 dev1 可 以 通过 ssh 连 接 服务 器 ， 使 用 setperms 命 令 为 自己 的 版 
授权 。 当 setperms 指 令 执 行 时 ， 会 启用 编辑 界面 ， 授 权 指 


次 
令 录 入 完毕 后 ， 输 入 ^D (CttltD) 结束 编辑 。 如 下 所 示 : 





$ ssh devi-server setperms users/devi/repos1.git 
R = dev2 
RW = jiangxin 
AD 





. 在 执行 setpetms 进 行 授 权时 ， 也 可 以 预先 将 授权 写 入 文件 ， 再 使 
用 输入 重 定向 ， 通 过 setpetms 命 令 加 载 ， 如 下 所 示 。 





$ cat > perms << EOF 
R = dev2 
RW = jiangxin 
EOF 
$ ssh deviQ@server setperms < perms 





用 户 可 以 使 用 getperms 查 看 为 自己 的 版 本 库 建 立 的 授权 。 





$ ssh devi@server getperms users/devi/repos1.git 
R = dev2 
RW = jiangxin 





30.4.4 对 引用 的 授权 : 传统 模式 


传统 的 引用 授权 指 的 是 授权 指令 中 不 包含 RWC、RWD、RWCD、 
RW+C、RW+D、RW+CD 授 权 关 键 字 ， 只 采用 RW 和 RW+ 的 传统 授权 关 
键 字 。 











在 只 使 用 传统 的 授权 关键 字 的 情况 下 ， 有 如 下 注意 事项 : 


“ 非 快 进 式 推送 必须 拥有 + 的 授权 。 


` 创建 引用 必须 拥有 W 的 授权 。 


" 删除 引用 必须 拥有 + 的 授权 。 


` 如 果 没 有 在 授权 指令 中 提供 引用 相关 的 参数 ， 相 当 于 提供 refs/* 
作为 引用 的 参数 ， 意 味 着 对 所 有 引用 均 有 效 。 








yA 下 
授权 文件 : 
1 @administrators = jiangxin admin 
2 @dev = dev1 dev2 badboy 
3 
4 repo test/repol1 
5 RW+ = @administrators 
6 RW master refs/heads/feature/ = @dev 
7 R = @test 
说 明 : 


` 第 5 行 ， 对 于 版 本 库 test/repol1， 管 理 员 组 用 户 jiangxin 和 admin 可 以 
任意 创建 和 删除 引用 ， 并 且 可 以 强制 推送 。 


" 第 6 行 的 规则 看 似 是 只 对 master 和 frefs/heads/feature/* 的 引用 授 
权 ， 实 际 上 @dev 可 以 读 取 所 有 名 字 空 间 的 引用 。 这 是 因为 读 取 操作 无 
法 获得 引用 相关 的 内 容 。 


即 用 户 组 @dev 的 用 户 只 能 对 master 分 文 ， 以 及 以 feature/ 开 头 的 分 文 
进行 写 操作 ， 但 不 能 强制 推送 和 删除 。 至 于 其 他 分 文 和 里 程 碑 ， 则 只 能 


读 不 能 写 


" 至 于 用 户 组 (@test 的 用 户 ， 因 为 使 用 了 R 授 权 指 令 ， 所 以 不 涉及 分 
支 的 写 授 权 。 


30.4.5 ”对 引用 的 授权 : 扩展 模式 





扩展 模式 的 引用 授权 ， 指 的 是 该 版 本 库 的 授权 指令 出 现 了 下 列 授权 
关键 字 中 的 一 个 或 多 个 : RWC、RWD、RWCD、RW+C、RW+D、 
RW+CD。 则 Gitolite 对 授权 采用 新 的 判定 方式 。 


非 快 进 式 推送 必须 拥有 + 的 授权 。 


` 创建 引用 必须 拥有 C 的 授权 。 


- 删除 引用 必须 拥有 D 的 授权 。 


即 引 用 的 创建 和 删除 使 用 了 单独 的 授权 关键 字 ， 和 写 权 限 和 强制 推 
送 权限 分 开 。 


下 面 是 一 个 采用 扩展 授权 关键 字 的 授权 文件 : 








repo test/repo2 
RW+C = @administrators 
RW+ = @dev 
RW = @test 

repo test/repo3 
RW+CD = @administrators 
RW+C = @dev 
RW = Qtest 





通过 上 面 的 配置 文件 ， 对 于 版 本 库 test/repo2.git 具 有 如 下 的 授权 : 


:用户 组 @administratots 中 的 用 户 ， 具 有 创建 和 删除 引用 的 权限 ， 
且 能 够 强制 推送 。 


. 用 户 组 (@dev 中 的 用 户 ， 不 能 创建 引用 ， 但 可 以 删除 引用 ， 并 且 
可 以 强制 推送 。 


-用户 组 (Qtest 中 的 用 户 ， 可 以 推送 到 任何 引用 ， 但 是 不 能 创建 引 
用 ， 不 能 删除 引用 ， 也 不 能 强制 推送 。 


通过 上 面 的 配置 文件 ， 对 于 版 本 库 testrepo3.git 具 有 如 下 的 授权 : 


-用户 组 @administratots 中 的 用 户 ， 具 有 创建 和 删除 引用 的 权限 ， 
并 且 能 够 强制 推送 。 


` 用 户 组 @dev 中 的 用 户 ， 可 以 创建 引用 ， 并 能 够 强制 推送 ,但 不 
能 删除 引用 。 


:用户 组 (Qtest 中 的 用 户 ， 可 以 推送 到 任何 引用 ， 但 是 不 能 创建 引 
用 ， 不 能 删除 引用 ， 也 不 能 强制 推送 。 


30.4.6 ”对 引用 的 授权 : 蔡 用 规则 的 使 用 


授权 文件 : 





1 repo testing 


12 RW refs/tags/v[0-9] 
13 - refs/tags/v[0-9] 
14 RW refs/tags/ 


jiangxin 
devi1 dev2 @others 
jiangxin dev1 dev2 @others 





说 明 : 
* 用 户 jiangxin 可 以 写 任 何 里 程 碑 ， 包括 以 v 加 上 数字 开头 的 里 程 
碑 。 


. 用 户 dev1、dev2 和 (@others 组 ， 只 能 写 除 了 以 Vv 加 上 数字 开关 之 外 
的 其 他 里 程 碑 。 


- 其 中 以 -开头 的 授权 指令 建立 共用 规则 。 蔡 用 规则 只 在 授权 的 第 
二 阶段 有 效 ， 因 此 不 能 限制 用 户 的 读 取 权 限 ! 


30.4.7 “用户 分 支 


和 创建 用 户 空 间 〈 使 用 了 CREATOR 关 键 字 ) 的 版 本 库 类 似 ， 还 可 
以 在 一 个 版 本 库 内 允许 管理 自己 名 字 空 间 (USER 关 键 字 ) 下 的 分 支 。 
在 正则 引用 的 参数 中 出 现 的 USER 关 键 字 会 被 蔡 换 为 用 户 的 ID。 











霸权 文件 ; 





repo test/repo4 
RW+CD = @administrators 
RW+CD refs/personal/USER/ = @all 
RW+ master = @dev 





说 明 : 


用 户 组 @administrators 中 的 用 户 ， 对 所 有 引用 具有 创建 和 删除 的 


权限 ， 并 且 能 强制 推送 。 


. 所 有 用 户 都 可 以 在 refs/personal/<userid>/ (自己 的 名 字 空 间 ) 下 
创建 和 删除 引用 。 但 是 不 能 修改 其 他 人 的 引用 。 


用 户 组 @dev 中 的 用 户 对 master 分 支 具 有 读 写 和 强制 更 新 的 权限 ， 


但 是 不 能 删除 。 





30.4.8 对 路 径 的 写 授 权 


Gitolite 也 实现 了 对 路 径 的 写 操作 的 精细 授权 ， 并 且 非 常 巧妙 的 是 : 
在 实现 上 增加 的 代码 可 以 忽略 不 计 。 这 是 因为 Gitolite 把 路 径 当 作 是 特殊 
格式 的 引用 的 授权 。 


在 授权 文件 中 ， 如 果 一 个 版 本 库 的 授权 指令 中 的 正则 引用 字段 出 现 
了 以 NAME/ 开 头 的 引用 ， 则 表明 该 授权 指令 是 针对 路 径 进 行 的 写 授 
权 ， 并 且 该 版 本 库 要 进行 基于 路 径 的 写 授 权 判 断 。 








1 repo foo 

2 = @junior_devs @senior_devs 
3 

4 RW NAME/ = @senior_devs 

5 NAME/Makefile = @junior_devs 

6 RW NAME/ 三 @junior_devs 





说 明 : 


. 第 2 行 ， 初 级 程序 员 (@junior_devs 和 高 级 程序 员 (@senior_devs 可 以 


对 版 本 库 foo 进 行 读 写 操作 。 

` 第 4 行 ， 设 定 高 级 程序 员 (@senior_devs 对 所 有 文件 (NAME/) 进 
行 写 操作 。 

" 第 5 行 和 第 6 行 ， 设 定 初 级 程序 员 (@junior_devs 对 除了 根 目 录 的 


Makefile 文 件 外 的 其 他 文件 具有 写 权 限 。 


[1] ”gitolite 是 安装 Gitolite 过 程 中 创建 的 主机 别名 ， 是 以 admin 用 户 身份 连 
接 Git 服 务 器 。 


[2] dev1l-setvet 是 别名 主机 ， 是 用 dev1 用 户 的 公 钥 访问 Setvet。 


30.5 ”创建 新 版 本 库 


Gitolite 维 护 的 版 本 库 默 认 位 于 安装 用 户主 目录 下 的 repositories 目 录 
中 ， 即 如 果 安 装 用 户 为 git， 则 版 本 库 都 创建 在 /home/git/repositories 目 录 
之 下 。 可 以 通过 配置 文件 .gitolite.rc 修 改 默认 的 版 本 库 的 根 路 径 。 





$REPO_BASE="repositories"， 


有 多 种 创建 版 本 库 的 方式 。 一 种 是 在 授权 文件 中 用 repo 指 令 设 置 版 
本 库 〈( 未 使 用 正则 表达 式 的 版 本 库 ) 的 授权 ， 当 对 gitolite-admin 版 本 库 
执行 git push 操 作 时 ， 目 动 在 服务 端 创建 新 的 版 本 库 。 另 外 一 种 方式 是 在 
授权 文件 中 用 正则 表达 式 定 义 的 通配符 版 本 库 ， 不 会 即时 创建 (也 不 可 
能 被 创建 )， 而 是 被 授权 的 用 户 在 远程 创建 后 推送 到 服务 器 上 完成 创 
建 。 


注意 : 在 授权 文件 中 出 现 的 版 本 库 名 称 不 要 带 .git 后 绥 ， 在 创建 厂 
本 库 过 程 中 会 自动 在 版 本 库 后 面 退 加 .git 后 级 。 








30.5.1 在 配置 文件 中 出 现 的 版 本 库 ， 即 时 生成 


尝试 在 授权 文件 conf/gitolite.conf 中 加 入 一 段 新 的 版 本 库 授 权 指 令 ， 
而 这 个 版 本 库 尚 不 存在 。 新 添加 到 授权 文件 中 的 内 容 为 : 





repo testing2 
RW+ = @all 








然后 将 授权 文件 的 修改 提交 并 推送 到 服务 器 ， 会 看 到 授权 文件 中 添 
加 新 授权 的 版 本 库 testing2 被 自动 创建 。 





$ git push 

Counting objects: 7, done. 

Delta compression using up to 2 threads. 

Compressing objects: 100% (3/3), done. 

Writing objects: 100% (4/4), 375 bytes, done. 

Total 4 (delta 1), reused 0 (delta 0) 

remote: Already on 'master' 

remote: creating testing2... 

remote: Initialized empty Git repository in /home/git/repositories/testing2.9git/ 

To gitadmin.bj:gitolite-admin.git 
278e54b..b6fO5c1 master -> master 





注意 其 中 带 remote 标 识 的 输出 ， 可 以 看 到 版 本 库 testing2.git 被 自动 
初始 化 了 。 


此 外 使 用 版 本 库 组 的 语法 〈 即 用 @ 创 建 的 组 ， 用 作 版 本 库 )， 也 会 
被 目 动 创建 。 例 如 下 面 的 授权 文件 片段 设 定 了 一 个 包含 两 个 版 本 库 的 组 
@testing， 妆 将 新 配置 文件 推送 到 服务 器 上 时 ， 会 自动 创建 testing3.git 和 
还 有 一 种 版 本 库 语 法 ， 是 用 正则 表达 式 定义 的 版 本 库 ， 这 类 版 本 库 因为 
所 指 的 版 本 库 并 不 确定 ， 因 此 不 可 能 自动 创建 。 





testing4.git。 

@testing = testing3 testing4 

repo @testing 
RW+ = @all 





还 有 一 种 版 本 库 语 法 ， 是 用 正则 表达 式 定 义 的 版 本 库 ， 这 类 版 本 库 


因为 所 指 的 版 本 库 并 不 确定 ， 因 此 不 可 能 上 自动 创建 。 





30.5.2 ”通配符 版 本 库 ， 管 理 员 通过 推送 创建 


通配符 版 本 库 是 用 正则 表达 式 语法 定义 的 版 本 库 ， 所 指 的 并 非 某 一 
个 版 本 库 而 是 和 名 称 相符 的 一 组 版 本 库 。 要 想 使 用 通配符 版 本 库 ， 需 要 
在 服务 器 端 Gitolite 的 安装 用 户 ( 如 git) 主 目录 下 ， 修 改 配置 文 
件 .gitolite.rc， 使 其 包含 如 下 配置 : 


$GL_WILDREPOS = 1; 


使 用 通配符 版 本 库 ， 可 以 对 一 组 版 本 库 进行 授权 ， 非 常 有 效 。 但 是 
版 本 库 的 创建 则 不 像 前 面 介绍 的 那样 ， 不 会 在 授权 文件 推送 到 服务 此 时 
创建 ， 而 是 由 拥有 版 本 库 创建 授权 (C)》 的 用 户 手 工 进行 创建 。 


对 于 用 通配符 设置 的 版 本 库 ， 用 C 指 令 指 定 能 够 创建 此 版 本 库 的 管 
理 员 《拥有 创建 版 本 库 的 授权 ) 。 例 如 : 


repo ossxp/.+ 
C = jiangxin 
RW = dev1 dev2 


管理 员 jiangxin 可 以 创建 路 径 符 合 正则 表达 式 “ossxp/.+” 的 版 本 库 ， 
用 户 dev1 和 dev2 对 版 本 库 具 有 读 写 《但 是 没有 强制 更 新 ) 权限 。 

















使 用 该 方法 创建 版 本 库 后 ， 创 建 者 的 uid 将 被 记录 在 版 本 库 目 录 下 
的 gl-creator 文 件 中 。 该 账号 具有 对 该 版 本 库 最 高 的 权限 。 该 通配符 版本 
库 的 授权 指令 中 如 果 出 现 CREATOR 将 被 创建 者 的 uid 蔡 换 。 








` 本 地 建 库 。 





$ mkdir somerepo 

$ cd somerepo 

$ git init 

$ git commit --allow-empty 





` 使 用 git remote 指 令 设 置 远程 版 本 库 。 





$ git remote add origin jiangxin-server 


:OSSxp/somerepo.git 





` 运行 git push 完 成 在 服务 器 端 版 本 库 的 创建 。 





$ git push origin master 








Gitolite 的 原始 实现 是 通配符 版 本 库 的 管理 员 在 对 不 存在 的 版 本 库 执 
行 clone 操 作 时 自动 创建 的 。 但 是 我 认为 这 不 是 一 个 好 的 实践 ， 经 常会 因 
为 在 元 隆 时 把 URL 写 错 ， 从 而 导致 在 服务 器 端 创建 垃圾 版 本 库 。 因 此 我 
重新 改造 了 gitolite 通 配 符 版 本 库 创 建 的 实现 方法 ， 改 为 在 对 版 本 库 进 行 





推送 的 时 候 进 行 创建 ， 而 clone 一 个 不 存在 的 版 本 库 会 报错 退出 。 


30.5.3 ”直接 在 服务 器 端 创建 


当 版 本 库 的 数量 很 多 的 时 候 ， 在 服务 器 端 直接 通过 git init 命 令 创 
建 ， 或 者 通过 复制 创建 可 能 会 更 方便 。 但 是 要 注意 ， 在 服务 器 端 手工 创 
建 的 版 本 库 和 Gitolite 创 建 的 版 本 库 最 大 的 不 同 在 于 钩子 脚本 。 如 采 不 能 
为 手工 创建 的 版 本 库 正 确 设 定 版 本 库 的 钩子 ， 会 导致 失去 Gitolite 特 有 的 
一 些 功 能 ， 例 如 失去 分 文 授 权 的 功能 。 




















一 个 由 Gitolite 创 建 的 版 本 库 ，hooks 目 录 下 有 三 个 钩子 脚本 实际 上 
链接 到 gitolite 安 装 目录 下 的 相应 的 脚本 文件 中 : 





gitolite-hooked -> /home/git/.gitolite/hooks/common/gitolite-hooked 
post-receive.mirrorpush -> /home/git/.gitolite/hooks/common/post-receive.mirrorpush 
update -> /home/git/.gitolite/hooks/common/update 











那么 手工 在 服务 器 上 创建 的 版 本 库 ， 有 没有 自动 更 新 钩子 脚本 的 广 
法 呢 ? 





第 一 个 方法 是 修改 Git 模 板 六 ， 在 创建 版 本 库 时 自动 创建 初始 的 钩 
子 脚本 。 再 有 就 是 重新 执行 一 遍 Gitolite 的 安装 ， 会 自动 更 新 版 本 库 的 钩 
子 脚本 。 安 装 过 程 一 路 按 回 车 即 可 。 


$ cd gitolite/src 
$ ./gl-easy-install git server admin 





除了 要 注意 钩子 脚本 以 外 ， 还 要 确保 服务 器 端 版 本 库 目 录 的 权限 和 
属 主 。 
站 jiangxin-setvet 是 设置 的 别名 主机 ， 是 以 jiangxin 用 户 的 公 钥 访问 Sefvet 
服务 器 。 


[2] 参见 第 8 篇 第 41 章 “41.2.2 Git 模 板 ” 的 相关 内 容 。 


30.6 ”对 Gitolite 的 改进 


笔者 对 Gitolite 进 行 扩 展 和 改进 ， 涉 及 的 内 容 主 要 包括 : 


` 通配符 版 本 库 的 创建 方式 和 授权 。 





原来 的 实现 是 克隆 即 创 建 ( 砚 隆 者 需要 说 授予 C 的 权限 ) 。 同 时 还 
要 通过 另外 的 授权 语句 为 用 户 设置 RW 权 限 ， 人 否则 创建 者 没有 读 和 写 的 
权限 。 





新 的 实现 是 通过 推送 创建 版 本 库 〈 推 送 者 需要 被 授予 C 权 限 ) 。 不 
必 再 为 创建 者 赋予 RW 等 权限 ,创建 者 自动 具有 对 版 本 库 最 遇 的 授权 。 














" 避免 通配符 版 本 库 的 误 判 。 





右 将 通配符 版 本 库 误 判 为 普通 版 本 库 名 称 ， 会 导致 在 服务 器 端 创建 
错误 的 版 本 库 。 新 的 设计 可 以 在 通配符 版 本 库 的 正则 表达 式 之 前 添加 ^ 
或 之 后 添加 $ 字 符 避 免 误 判 。 


. 改变 默认 配置 。 


默认 安装 即 文 持 通配符 版 本 库 。 


` 版 本 库 重 定向 。 





Gitosis 的 一 个 很 重要 的 功能 版 本 库 名 称 重 定 同 ， 没 有 在 Gitolite 
中 实现 。 我 为 Gitolite 增 加 了 这 个 功能 。 





在 Git 服 务 器 架设 的 初期 ， 版 本 库 的 命名 可 能 非常 随意 ， 例 如 ， 
redmine 的 版 本 库 直 接 放 在 根 下 : redmine-0.9.x.git、redmine-1.0.x.git... 随 
着 redmine 项 目 越 来 越 复杂 ， 可 能 就 需要 将 其 放 在 子 目 录 下 进行 管理 ， 
例如 放 到 ossxp/redmine/ 目 录 下 。 只 需要 在 Gitolite 的 授权 文件 中 添加 下 面 
一 行 map 语 句 ， 就 可 以 实现 版 本 库 名 称 的 重 定向 。 使 用 旧地 址 的 用 户 不 
必 重 新 检 出 ， 可 以 继续 使 用 。 











map (redmine.*) = ossxp/redmine/$1 





30.7 ”Gitolite 功 能 拓展 


30.7.1 版 本 库 镜 像 [1 


1. 版 本 库 镜 像 的 用 途 和 原理 


Git 版 本 库 控制 系统 往往 并 不 需要 设计 特别 的 容 灾 备份 ， 因 为 每 一 
个 Git 用 户 瑟 是 一 个 备份 。 但 是 下 面 的 情况 ， 就 很 有 必要 考虑 容 灾 了 。 


* Git 版 本 库 的 使 用 者 很 少 〈 每 个 库 可 能 只 有 一 个 用 户 ) 。 


. 版 本 库 克 隆 只 限制 在 办 公 区 并 且 服 务 器 也 在 办 公 区 内 (所 有 鸡蛋 
都 在 一 个 篮子 里 ) 。 


Git 版 本 库 采 用 集中 式 的 应 用 模型 ， 需 要 建立 双 机 热 备 ( 以便 在 
故障 出 现时 ， 实 现 快速 的 服务 器 切换 ) 。 


Gitolite 提 供 了 服务 需 间 版 本 库 同步 的 设置 。 原 理 是 : 


. 主 服务 器 通过 配置 文件 ~/.pgitolite.fc 中 的 变量 $ENV{GL SLAVES} 
设置 镜像 服务 器 的 地 址 。 


. 从 服务 器 通过 配置 文件 ~/.pgitolite.fc 中 的 变量 $GL_SLAVE_MODE 
式 


设置 为 从 服务 器 模 


O 


. 从 主 服务 器 端 运行 脚本 gmittot-sync 可 以 实现 批量 的 版 本 库 镜 


. 主 服务 器 的 每 一 个 版 本 库 都 配置 post-receive 钓 子 ， 一旦 有 提交 ， 
即时 同步 到 镜像 版 本 库 。 
2. 版 本 库 镜 像 的 实现 方法 
在 多 个 服务 器 之 间 设 置 Git 库 镜像 的 方法 是 : 
(1) 每 个 服务 器 都 要 安装 Gitolite 软 件 ， 而 且 要 启用 post-receive 钩 
子 。 默 认 的 钧 子 在 源 代码 的 hooks/common 目 录 下 ， 名 称 为 post- 


receive.mirrorpush， 要 将 其 改名 为 post-receive。 人 否则 版 本 库 的 post- 
receive 脚 本 不 能 生效 。 


(2) 主 服务 器 配置 到 从 服务 器 的 公 钥 认证 ， 配 置 使 用 特殊 的 
shell: gl-mirror-shell。 





这 是 因为 主 服务 器 在 向 从 服务 器 同步 版 本 库 的 时 候 ， 如 果 没 有 创建 
从 服务 器 上 相应 的 版 本 库 ， 则 需要 直接 通过 SSH 登 录 到 从 服务 器 ， 执 行 
创建 命令 创建 版 本 库 。 因 此 需要 通过 一 个 特殊 的 shell， 能 够 同时 支持 
Gitolite 的 授权 访问 及 shel 环 境 。 这 个 特殊 的 shell 就 是 gl-mirror-shell。 而 
有 这 个 shell 可 以 通过 特殊 的 环境 变量 绕 过 服务 器 的 权限 检查 ， 避 和 免 因为 
授权 问题 而 导致 同步 失败 。 








实际 应 用 中 ， 不 光 主 服务 器 ， 每 个 服务 器 都 要 进行 类 似 设置 ， 目 的 
是 主 从 服务 器 可 能 相互 切换 。 注 意 : 在 Gitolite 不 同 的 安装 模式 下 ，gl- 
mirror-shell 的 安装 位 置 可 能 不 同 。 


下 面 的 命令 用 于 更 改 服务 器 端 Gitolite 安 装 用 户 的 
~/.ssh/authorized_keys 配 置 文件 ， 以 便 使 用 特定 公 钥 的 其 他 服务 器 在 访问 
本 服务 器 时 使 用 这 个 特殊 的 shell。 假 设 在 服务 器 foo 上 ， 配 置 服务 右 bar 
和 baz 使 用 特殊 的 shell， 而 来 自 这 两 个 服务 器 的 连接 分 别 使 用 bar.pub 和 
baz.pub 两 个 公 钥 文件 。 


' 对 于 以 客户 端 安 装 方式 部 署 的 Gitolitet， 可 以 通过 下 面 的 方法 确定 
gl-mirror-shell 的 位 置 ， 然 后 修改 ~/.ssh/authorized_keys 文 件 。 





# 在 服务 器 foo 上 执行 : 
$ export GL_ADMINDIR= ”cd $HOME;perl] -e 'do ".gitolite.rc"; print $GL ADMINDIR'. 
$ cat bar.pub baz.pub | 
sed -e 's, ^, command="'$GL ADMINDIR'/src/gl-mirror-shell" , ' >> 
~/.ssh/authorized_keys 








. 对 于 以 服务 器 端 安装 方式 部 署 的 Gitolite， 可 以 在 路 径 中 找到 gl- 
mirror-shell， 进 而 设置 ~/.ssh/authotrized_keys 文 件 。 





~/ .Ssh/authorized_keys 文 件 。 

# 在 服务 器 foo 上 执行 : 

$ cat bar.pub baz.pub | 
sed -e 's, ^, command="'$(which gl-mirror-shell)'" , ' >> ~/.ssh/authorized_keys 











(3) 在 foo 服 务 嚣 上 设置 完毕 后 ， 可 以 从 服务 器 bar 或 baz 上 远程 执 


$ ssh git@foo pwd 





. 讲 入 shell。 


$ ssh git@foo bash -i 


(4) 在 从 服务 器 上 设置 配置 文件 ~/.gitolite.rc。 


进行 如 下 设置 后 ， 将 不 允许 用 户 直接 推送 到 从 服务 器 。 但 是 主 服务 
器 仍然 可 以 推送 到 从 服务 器 ， 是 因为 主 服务 器 版 本 库 在 推送 到 从 服务 器 
时 ， 使 用 了 特殊 的 环境 变量 ， 能 够 跳 过 从 服务 器 版 本 库 的 update 脚 本 。 


$GL_SLAVE_MODE = 1 





(5) 在 主 服 务 器 上 设置 配置 文件 ~/.gitolite.rc。 


再 要 配置 到 从 服务 器 的 SSH 连 接 ， 可 以 设置 多 个 ， 用 空格 分 隔 。 注 
意 使 用 单 引号 ， 以 避免 @ 字 符 被 Penl 当 作 数 组 解析 。 





$ENV{GL_SLAVES} = 'gitolite@bar gitolite@baz'; 


(6) 在 主 服 务 右 端 执 行 g-mirror-sync 进 行 一 次 完整 的 数据 同步 。 


需要 以 Gitolite 安 装 用 户 的 号 份 〈 如 git) 执行 。 例 如 在 服务 圳 foo 上 
执行 到 从 服务 器 bar 的 同步 。 


$ gl-mirror-sync gitolite@bar 





(7) 之 后 ， 用 户 每 次 回 主 版 本 库 同步 ， 都 会 通过 版 本 库 的 post- 
receive 钓 子 即时 同步 到 从 版 本 库 。 


当主 版 本 库 出 现 故 障 时 ， 就 需要 把 从 服务 器 切换 为 主 服务 器 模式 ， 
这 就 需要 进行 主 从 版 本 库 的 切换 设置 。 切 换 非 常 简单 ， 就 是 修改 
~/.gitolite.rc 配 置 文件 ， 修 改 $4GL_SLAVE_MODE 设 置 : 主 服 务 器 设置 为 
0， 从 服务 器 设置 为 1。 注 意 在 主 服务 器 恢复 之 前 ， 要 修改 主 服 务 器 的 配 
置 使 之 降级 为 从 服务 器 ， 否 则 主 服 务 器 恢复 工作 后 会 造成 同时 存在 多 个 
主 服务 器 ， 从 而 导致 数据 的 相互 履 新 。 


30.7.2 ”Gitweb 和 Git daemon 文 持 
Gitolite 和 git-daemon 的 整合 很 简单 ， 就 是 由 Gitolite 创 建 的 版 本 库 会 
在 版 本 库 目 录 中 创建 一 个 空 文件 git-daemon-export-ok。 


Gitolite 和 Gitweb 的 整合 则 提供 了 两 个 方面 的 内 容 。 一 个 是 可 以 设置 
版 本 库 的 描述 信息 ， 用 于 在 Gitweb 的 项 目 列表 页 面 中 显示 。 另 外 一 个 是 
自动 生成 项 目的 列表 文件 供 Gitweb 参 考 ， 避 免 Gitweb 使 用 低 效 率 的 目录 





递归 搜索 查找 Git 版 本 库 列表 。 





可 以 在 授权 文件 中 设 定 版 本 库 的 描述 信息 ， 并 在 gitolite-admin 管 理 
库 更 新 时 创建 到 版 本 库 的 description 文 件 中 。 





reponame = "one line of description" 
reponame "owner name" = "one line of description" 





第 1 行 ， 为 名 为 feponame 的 版 本 库 设 定 描述 


. 第 2 行 ， 同 时 设 定 版 本 库 的 属 主 名 称 ， 以 及 一 行 版 本 库 描 述 


对 于 通配符 版 本 库 ， 使 用 这 种 方法 则 很 不 现实 。Gitolite 提 供 了 SSH 
子 命令 供 版 本 库 的 创建 者 使 用 。 





$ ssh git@server setdesc path/to/repos.git 
$ ssh git@server getdesc path/to/repos.git 





. 第 一 条 指令 用 于 设置 版 本 库 的 描述 信息 
. 第 二 条 指令 显示 版 本 库 的 描述 信息 


至 于 生成 Gitweb 所 用 的 项 目 列表 文件 ， 默 认 创 建 在 用 户主 目录 下 的 
projects.list 文 件 中 。 对 于 所 有 启用 Gitweb 的 [repo] 小 节 所 设 定 的 版 本 库 ， 
以 及 通过 版 本 库 描 述 隐 式 声明 的 版 本 库 部 会 加 入 到 版 本 库 列 表 中 。 





30.7.3 ”其 他 功能 拓展 和 参考 


Gitolite 源 码 的 doc 目 录 包 含 用 markdown 标 记 语 言 编写 的 手册 ， 可 以 
直接 在 Github 上 和 查看。 也 可 以 使 用 markdown 的 文档 编辑 工具 将 .mkd 文 档 
转换 为 html 文 档 。 转 换 工 具 很 多 ， 有 rdiscount、Bluefeather、Maruku、 


BlueCloth2， 等 等 。 





在 这 些 参 考 文档 中 ， 用 户 可 以 发 现 Gitolite 包 含 的 更 多 的 小 功能 或 秘 
和 包括 : 


` 版 本 库 设 置 。 


授权 文件 通过 git config 指 令 为 版 本 库 进行 附加 的 设置 。 例 如 : 





repo gitolite 
config hooks.mailinglist = gitolite-commits@example.ti1d 
config hooks.emailprefix = "[gitolite] " 
config foo.bar = "" 
config foo.baz = 





“ 多 级 管理 员 授 权 。 





可 以 为 不 同 的 版 本 库 设 定 管理 员 ， 操 作 gitolite-admin 库 的 部 分 授权 
文件 。 具 体 参 考 : doc/5-delegation.mkd。 


" 自 定义 钩子 脚本 。 





因为 Gitolite 占 用 了 几 个 钩子 脚本 ， 如 果 需 要 对 同名 钩子 进行 扩展 ， 
Gitolite 提 供 了 级 联 的 钩子 脚本 ， 将 定制 放 在 级 联 的 钩子 脚本 里 。 


例如 ;通过 自 定 义 gitolite-admin 的 post-update.secondary 肢 本， 以 实 
现 无 须 登录 服务 器 即 可 更 改 .gitolite.rc 文 件 。 具 体 参 考 : doc/shell- 


games.mkd。 





关于 钩子 脚本 的 创建 和 维护 ， 具 体 参 考 : doc/hook- 


Propagation.mkd 。 


. 管理 员 自 定义 命令 。 








通过 设置 配置 文件 中 的 $GL_ADC_ PATH 变量 ， 在 远程 执行 该 目录 
下 的 可 执行 脚本 ， 如 : rmrepo。 


具体 参考 : doc/admin-defined-commands.mkd。 
. 创建 匿名 的 SSH 认 证 。 


允许 匿名 用 户 访问 Gitolite 提 供 的 Git 服 务 。 即 建立 一 个 和 Gitolite 服 
务 器 端 账号 同 ID 同 主 目录 的 用 户 ， 设 置 其 的 特定 shell， 并 且 人 允许 口令 为 








内 


具体 参考 : docmob-branches.mkd。 


. 可 以 通过 名 为 @all 的 版 本 库 进行 全 局 的 授权 。 


但 是 不 能 在 @all 版 本 库 中 对 @all 用 户 组 进行 授权 。 


` 版 本 库 或 用 户 非常 之 多 ( 几 千 个 ) 的 时 候 ， 需 要 使 用 大 配置 文件 
模式 。 


因为 Gitolite 的 授权 文件 要 先 编译 才能 生效 ， 而 编译 文件 的 大 小 是 和 
用 户 及 版 本 库 数量 的 乘积 成 正比 的 。 选 择 大 配置 文件 模式 则 不 对 用 户 组 
和 版 本 库 组 进行 扩展 。 


具体 参考 : docbig-config.mkd。 
. 授权 文件 支持 包含 语句 ， 可 以 将 授权 文件 分 成 多 个 独立 的 单元 。 
` 执行 外 部 命令 ， 如 fsync。 


. Subvetsion 版 本 库 支 持 。 


如 果 在 同一 个 服务 器 上 以 svn+ssh 方 式 运 行 Subversion 服 务 器 ， 可 以 
使 用 同一 套 公 和 钥 ， 同 时 为 用 户 提 供 Git 和 Subversion 服 务 。 


" HTTP 口 令 文 件 维 护 。 通 过 名 为 htpasswd 的 SSH 子 命令 实现 。 


[1] 本 节 内 容 不 适用 于 Gitolite 2.1 或 更 新 的 版 本 。 使 用 新 版 本 Gitolite 设 置 
版 本 库 镜 像 可 参见 我 的 博客 : http://www.worldhello.net/2011/11/30/03- 


gitolite-mirror.html。 


第 31 童 ”Gitosis 服 务 架 设 


Gitosis 是 Gitolite 的 锚 祖 ， 同 样 也 是 一 款 基 于 SSH 公 钥 认 证 的 Git 服 务 
管理 工具 ， 但 是 功能 要 比 之 前 介绍 的 Gitolite 弱 一 些 。Gitosis 由 Python 语 
言 开 发 ， 对 于 偏爱 Python 不 喜欢 Perl 的 开发 者 (我 就 是 其 中 之 一 ) ， 可 
以 对 Gitosis 加 以 关注 。 


Gitosis 的 出 现 远 早 于 Gitolite， 作 者 Tommi Virtanen 从 2007 年 5 月 就 开 
始 了 Gitosis 的 开发 ， 最 后 一 次 提交 是 在 2009 年 9 月 ， 已 经 停止 更 新 了 。 
但 是 Gitosis 依 然 有 其 生命 力 。 


` 配置 简洁 ， 可 以 直接 在 服务 器 端 编辑 ， 可 成 为 针对 茶 些 服务 定制 
的 、 内 置 的 、 无 须 管理 的 Git 服 务 。 


Gitosis 的 配置 文件 非常 简单 ， 直 接 保 存 于 服务 安装 用 户 《〈 如 git) 的 
主 目录 下 的 .gitosis.conf 文 件 中 ， 可 以 直接 在 服务 器 端 创建 和 编辑 。 而 与 
之 相 比 ，Gitolite 的 授权 文件 需要 复杂 的 编译 ， 一 般 需 要 管理 员 殉 隆 
gitolite-admin 库 ， 远 程 编辑 并 推送 至 服务 器 。 若 要 用 Gitolite 实 现 一 个 无 
须 管 理 的 Git 服 务 ， 难 度 要 大 很 多 。 


.支持 版 本 库 重 定向 。 














版 本 库 重 定 同 一 方面 在 版 本 库 路 径 变更 后 保持 旧 的 URL 仍 可 工作 ， 


另 一 方面 用 在 客户 端 ， 以 简洁 的 地 址 屏蔽 服务 器 端 复杂 的 地 址 。 例 如 我 
开发 的 一 款 备 份 工具 〈Gistore) ， 版 本 库 位 

于 /etc/gistore/tasks/systemy/repo.git〈 符 号 链接 ) ， 客 户 端 使 用 system.git 
即 映射 到 复杂 的 服务 器 端 地 址 。 


注 : 我 在 定制 的 Gitolite， 这 个 功能 也 已 实现 。 


- Python 语言 开发 ， 对 于 喜欢 Python 不 喜欢 Perl 的 用 户 可 以 选择 


Gilitosis 。 


` 在 Github 上 有 很 多 Gitosis 的 克隆 ， 我 对 Gitosis 的 改动 放 在 了 github 


http://github.com/ossxp-com/gitosis 。 


为 Gitosis 是 Gitolite 的 鼻祖 ， 因 此 下 面 介绍 的 Gitosis 实 现 机 理会 让 
您 感到 似曾相识 : 


* Gitosis 安 装 在 服务 器 (如 server) 的 某 个 账号 (如 pgit) 之 下 。 


vw 


理 员 通过 git 命 令 检 出 名 为 gitosis-admin 的 版 本 库 。 


性 





$ git clone git@server:gitosis-admin.git 





` 管理 员 将 git 用 户 的 公 角 保存 在 gitosis-admin 库 的 keydit 目 录 下 ， 并 


编辑 gitosis.conf 文 件 为 用 户 授权 。 
. 当 管 理 员 提交 对 gitosis-admin 库 的 修改 并 推送 到 服务 器 之 后 ， 服 务 


器 上 8gitosis-admin 版 本 库 的 钩子 脚本 将 执行 相应 的 设置 工作 。 


- 新 用 户 公 铀 自动 追加 到 服务 器 端 安 装 账号 用 户主 目录 中 
的 .ssh/authorized_keys 文 件 中 ， 并 设置 新 用 户 的 登录 shell 为 gitosis 的 一 条 


命令 gitosis-serve。 





command="gitosis-serve 
jiangxin", no-port-forwarding, no-X11-forwarding, no-agent-forwarding, no 


-pty ssh-rsa < 公 钥 内 容 来 自 于 jiangxin.pub ...> 








. 更 新 服务 器 端的 授权 文件 ~ /.gitosis.conf。 
. 用 户 可 以 用 Git 命 令 访 问 授权 的 版 本 库 。 
当 管 理 员 授权 后 ， 用 户 可 以 远程 在 服务 器 上 创建 新 版 本 库 。 


下 面 介绍 Gitosis 的 部 署 和 使 用 。 在 下 面 的 示例 中 约定 : 服务 器 的 名 
称 为 server，Gitosis 的 安装 账号 为 git。 


31.1 安装 Gitosis 


Gitosis 的 部 晋 和 使 用 可 以 直接 参考 源 代 码 中 的 README.rst。 可 以 
直接 访问 Github 上 我 的 Gitosis 克 隆 ， 因 为 Github 能 够 直接 将 rst 文 件 显 示 
为 网 页 。 





http://github.com/ossxp-com/gitosis/blob/master/README.rst 





31.1.1 ”Gitosis 的 安装 


Gitosis 的 官方 Git 库 位 于 git://eagain.net/gitosis.git。 我 在 Github 上 创建 
了 一 个 克隆 由 。Gitosis 的 安装 需要 在 服务 器 端 执行 。 下 面 介 绍 直接 从 源 
代码 进行 安装 ， 以 便 获 得 最 新 的 改进 。 


. 使 用 Git 下 载 Gitosis 的 源 代 码 。 





$ git clone git://github.com/ossxp-com/gitosis.git 





. 进入 gitosis 目 录 ， 执 行 安 装 。 





$ cd gitosis 
$ sudo python setup.py install 





可 执行 脚本 安装 在 /usr/local/bin 目 录 下 。 





$ ls /usr/local/bin/gitosis-* 
/usr/local/bin/gitosis-init /usr/local/bin/gitosis-run-hook 
/usr/local/bin/gitosis-serve 





31.1.2 ”服务 器 端 创建 专用 账号 


安 浇 Gitosis， 还 需要 在 服务 器 剖 创 建 专用 账号 ， 所 有 用 户 都 通过 此 
账号 访问 Git 库 。 一 般 为 方便 易 记 ， 选 择 git 作 为 专用 账号 名 称 。 





$ sudo adduser --system --shell /bin/bash --disabled-password --group git 





创建 用 户 git， 并 设置 用 户 的 shell 为 可 登录 的 shell， 如 /bin/bash， 同 
时 添加 同名 的 用 户 组 。 


有 的 系统 ， 只 允许 特定 用 户 组 (如 ssh 用 户 组 ) 的 用 户 才 可 以 通过 
SSH 协 议 登 录 ， 这 就 需要 将 新 建 的 git 用 户 添加 到 ssh 用 户 组 中 。 





$ sudo adduser git ssh 





31.1.3 ”Gitosis 服 务 初始 化 


Gitosis 服 务 初 始 化 ， 就 是 初始 化 一 个 gitosis-admin 库 ， 并 为 管理 员 
分 配 权 限 ， 还 要 将 Gitosis 管 理 员 的 公 钥 添加 到 专用 账号 的 


~/.ssh/authorized_keys 文 件 中 ， 具 体操 作 过 程 如 下 。 


(1) 如 果 管 理 员 在 客户 端 没有 公 钥 ， 使 用 下 面 的 命令 创建 。 





$ ssh-keygen 





(2) 管理 员 上 传 公 钥 到 服务 器 。 





$ scp ~/.Sssh/id_rsa,.pub server:/tmp 





(3) 服务 器 端 进行 Gitosis 服 务 初始 化 。 


以 git 用 户 身 份 执行 gitosis-init 命 令 ， 并 向 其 提供 管理 员 公 钼 。 





$ sudo Su - git 
$ gitosis-init < /tmp/id_rsa.pub 





(4) 确保 gitosis-admin 版 本 库 的 钩子 脚本 可 执行 。 





$ sudo chmod a+x ~git/repositories/gitosis-admin.git/hooks/post-update 





[1] http:/ /github.com/ossxp-com/ gitosis 


31.2 ”管理 Gitosis 


31.2.1 ”管理 员 元 隆 gitolit-admin 管 理 库 


当 Gitosis 安 装 完成 后 ， 在 服务 器 端 自动 创建 了 一 个 用 于 Gitosis 自 身 
管理 的 Git 库 : gitosis-admin.git。 


管理 员 在 客户 端 克 隆 gitosis-admin.git 库 ， 注 意 要 确保 认证 中 使 用 的 
是 正确 的 公 包 : 





$ git clone git@server:gitosis-admin.git 
$ cd gitosis-admin/ 

$ ls -F 

gitosis.conf keydir/ 

$ ls keydir/ 

jiangxin.pub 





可 以 看 出 gitosis-admin 目 录 下 有 一 个 配置 文件 和 一 个 目录 keydir。 
keydir/jiangxin.pub 文 件 


keydir 目 录 下 初始 时 只 有 一 个 用 户 公 钥 ， 即 管理 员 的 公 钥 。 管 理 员 
的 用 户 名 来 自 公 钥 文 件 末尾 的 用 户 名 。 


gitosis.conf 文 件 


该 文件 为 授权 文件 。 初 始 内 容 为 : 


[gitosis] 


[group gitosis-admin] 
writable = gitosis-admin 
members = jiangxin 


UP 





可 以 看 到 授权 文件 的 语法 完全 不 同 于 之 前 介绍 的 Gitolite 的 授权 文 
件 。 整 个 授权 文件 以 用 户 组 为 核心 ， 而 非 版 本 库 为 核心 。 


第 3 行 开 始 定义 了 一 个 用 户 组 gitosis-admin。 
- 第 5 行 设 定 了 该 用 户 组 包含 的 用 户 列表 。 
初始 时 只 有 一 个 用 户 ， 即 管理 员 公 钥 所 属 的 用 户 。 


. 第 4 行 设 定 了 该 用 户 组 对 哪些 版 本 库 具有 写 操作 。 





在 这 里 ， 配 置 对 gitosis-admin 版 本 库 具 有 写 操 作 。 写 操作 自动 包含 
了 读 操 作 。 


31.2.2 ”增加 新 用 户 


增加 新 用 户 ， 就 是 允许 新 用 户 能 够 通过 其 公 钼 访问 Git 服 务 。 只 要 
将 新 用 户 的 公 钥 添加 到 gitosis-admin 版 本 库 的 keydir 目 录 下 ， 即 完成 新 用 
户 的 添加 ， 具 体操 作 过 程 如 下 。 


(1) 管理 员 从 用 户 获取 公 铀 ， 并 将 公 钥 按照 username.pub 格 式 进行 


重 命名 。 


用 户 可 以 通过 邮件 或 其 他 方式 将 公 钥 传递 给 管理 员 ， 切 记 不 要 将 私 
钥 误 传 给 管理 员 。 如 果 发 生 私 钥 泄露 ， 马 上 重新 生成 新 的 公 钥 / 私 钥 
对 ， 并 将 新 的 公 钥 传递 给 管理 员 ， 并 申请 将 旧 的 公 钥 作废 。 


关于 公 钥 名 称 ， 我 引入 了 类 似 Gitolite 的 实现 : 


用 户 从 不 同 的 客户 端 主机 访问 有 着 不 同 的 公 钥 ， 如 果 希 望 使 用 同 
一 个 用 户 名 进行 授权 ， 可 以 按照 username(@host.pub 的 方式 命名 公 钥 文 
件 ， 和 名 为 username(@pub 的 公 和 钥 指 向 同一 个 用 户 username。 


` 也 支持 邮件 地 址 格式 的 公 钥 ， 即 形 如 username(@gmail.com.pub 的 
公 钥 。Gitosis 能 够 很 智能 地 区 分 是 以 邮件 地 址 命名 的 公 铀 还 是 相同 用 户 
在 不 同 主机 上 的 公 钥 。 如 果 是 邮件 地 址 命名 的 公 钥 ， 将 以 整个 邮件 地 址 
作为 用 户 名 。 


(2) 管理 员 进 入 gitosis-admin 本 地 克隆 版 本 库 中 ， 复 制 新 用 户 公 针 
到 keydir 目 录 。 





$ cp /path/to/devi.pub keydir/ 
$ cp /path/to/dev2.pub keydir/ 





(3) 执行 git add 命 令 ， 将 公 钥 添加 到 版 本 库 。 





$ git add keydir 
$ git status 


# On branch master 
# Changes to be committed : 
(use "git reset HEAD <file>..." to unstage) 


new file: keydir/devi.pub 
new file: keydir/dev2.pub 


亲 亲 闪闪 和 亲 





(4) 执行 git commit， 完 成 提交 。 





$ git commit -m "add user: dev1， dev2" 

[master d7952a5] add user: dev1， dev2 

2 files changed, 2 insertions(+), 0 deletions(-) 
create mode 100644 keydir/devi.pub 

create mode 100644 keydir/dev2.pub 





(5) 执行 git push， 同 步 到 服务 器 ， 才 真正 完成 新 用 户 的 添加 。 





$ git push 

Counting objects: 7, done. 

Delta compression using up to 2 threads. 

Compressing objects: 100% (5/5), done. 

Writing objects: 100% (5/5), 1.03 KiB, done. 

Total 5 (delta 0), reused 0 (delta 0) 

To git@server:gitosis-admin.git 
2482e1b..d7952a5 master -> master 





如 果 这 时 查看 服务 器 端 ~git/.ssh/authorized_keys 文 件 ， 会 发 现 新 增 
的 用 户 公 钥 也 附加 在 其 中 : 





### autogenerated by gitosis, DO NOT EDIT 

command="gitosis-serve 

jiangxin", no-port-forwarding, no-X11-forwarding, no-agent-forwarding, no-pty 

< 用 户 jiangxin 的 公 钥 .. .> 

ommand="gitosis-serve 

evi1i", no-port-forwarding, no-X11-forwarding, no-agent-forwarding, no-pty ssh-rsa 
j 户 dev1 的 公 钥 ...> 

ommand="gitosis-serve 

ev2", no-port-forwarding, no-X11-forwarding, no-agent-forwarding, no-pty ssh-rsa 
户 dev1 的 公 钥 ,. .> 


| 









































31.2.3 ”更 改 授权 


新 用 户 添 加 完毕 后 ， 可 能 需要 重新 进行 授权 。 更 改 授权 的 方法 也 非 
简单 ， 即 修改 gitosis.conf 配 置 文件 ， 提 交 并 推送 ， 具 体操 作 过 程 如 


第 
Fy 





(1) 首先 ， 管 理 员 进 入 gitosis-admin 本 地 克隆 版 本 库 中 ， 编 辑 


gitosis.conf。 





$ vi gitosis.conf 





(2) 授权 指令 比较 复杂 ， 先 通过 建立 一 个 新 用 户 组 并 授权 新 版 本 
库 testing 壬 试 一 下 更 改 授 权 文件 。 例 如 在 gitosis.conf 中 添加 如 下 的 授权 


内 容 : 





[group testing-admin] 
members = jiangxin @gitosis-admin 
admin = testing 


1 

之 

3 

4 

5 [group testing-devloper] 
6 members = dev1 dev2 
7 writable = testing 

8 
9 
0 
1 


[group testing-reader] 
members = @all 
readonly = testing 





上 面 的 授权 文件 为 版 本 库 testing 赋 予 了 三 个 角色 。 分 别 是 
(Qtesting-admin 用 户 组 、(Q@testing-developet 用 户 组 和 (Q@testing-reader 用 户 


组 。 


第 1 行 开始 的 testngradmin 小 节 ， 定 义 了 用 户 组 Qtesting-admin。 


. 第 2 行 设 定 该 用 户 组 包含 的 用 户 有 jiangxin， 以 及 前 面 定 义 的 


(Qeitosis-admin 用 户 组 用 户 。 


- 第 3 行 用 admin 指 令 ， 设 定 该 用 户 组 用 户 可 以 创建 版 本 库 testing。 
admin 指 令 是 笔者 新 增 的 授权 指令 ， 请 确认 安装 的 Gitosis 包 含 笔 者 的 改 


进 。 


` 第 7 行 用 writable 授 权 指 令 ， 设 定 该 Qtesting-developet 用 户 组 用 户 可 
以 读 写 版 本 库 testing。 笔 者 改进 后 的 Gitosis 也 可 以 使 用 write 作 为 writable 
指令 的 同义词 指令 。 


第 11 行 用 fteadonly 授 权 指 令 ， 设 定 该 Qtesting-teadef 用 户 组 用 户 
(所 有 用 户 ) 可 以 只 读 访 问 版 本 库 testing。 笔 者 改进 后 的 Gitosis 也 可 以 
使 用 read 作 为 readonly 指 令 的 同义词 指令 。 





(3) 编辑 结束 ， 提 区 改动 。 





$ git add gitosis,conf 
$ git commit -q -m "auth for repo testing." 





(4) 执行 git push， 同 步 到 服务 器 ， 才 真正 完成 授权 文件 的 编辑 。 





$ git push 





31.3 ”Gitosis 授 权 详 解 


31.3.1 ”Gitosis 默 认 设 置 


在 [gitosis] 小 节 中 定义 Gitosis 的 默认 设置 如 下 : 





[gitosis] 

repositories = /gitroot 
#10glevel=DEBUG 

gitweb = yes 

daemon = yes 

generate-files-in = /home/git/gitosis 


OODP 





其 中 : 


. 第 2 行 ， 设 置 版 本 库 默 认 的 根 目 录 是 /gitroot 目 录 。 否 则 默认 的 路 


径 是 安装 用 户主 目录 下 的 repositories 目 录 。 


“ 第 3 行 ， 如 果 打 开 注 释 ， 则 版 本 库 操 作 时 显示 Gitosis 的 调试 信 


` 第 5 行 ， 启 用 git-daemon 的 整合 。 即 在 新 创建 的 版 本 库 中 ， 创 建文 


件 git-daemon-export-ok。 


第 6 行 ， 设 置 创 建 的 项 目 列表 文件 〈 供 Gitweb 使 用 ) 所 在 的 目 
录 。 默 认为 安装 用 户主 目录 下 的 gitosis 目 录 。 





31.3.2 ”管理 版 本 库 gitosis-admin 





1 [group gitosis-admin] 

2 write = gitosis-admin 

3 members = jiangxin 

4 repositories = /home/git 





除了 第 4 行 ， 其 他 内 容 在 前 面 都 已 经 介绍 过 了 ， 是 Gitosis 自 身 管理 
版 本 库 的 用 户 组 设置 。 


第 4 行 ， 重 新 设置 了 版 本 库 的 默认 根 路 经 ， 禾 盖 默 认 的 [gitosis] 小 市 
中 的 默认 根 路 符 。 实 际 的 gitosis-admin 版 本 库 的 路 径 为 /home/git/gitosis- 


admin.git。 





31.3.3 ”定义 用 户 组 和 授权 





下 面 的 两 个 示例 小 节 定 义 了 两 个 用 尸 组， 并且 用 到 了 路 径 变换 的 指 





[group ossxp-admin] 

members = @gitosis-admin jiangxin 

admin = ossxp/** 

read = gistore/* 

map admin redmine-* = ossxp/redmine/\1 

map admin ossxp/redmine-* = ossxp/(redmine-.*):ossxp/redmine/\1 
map admin ossxp/testlink-* = ossxp/(testlink-.*):ossxp/testlink/\1 
map admin ossxp/docbones* = ossxp/(docbones.*):ossxp/docutils/\1 


‘ONOORODPp 


10 [group alll] 

11 read = ossxp/** 

12 map read redmine-* = ossxp/redmine/\1 

13 map read testlink-* = ossxp/testlink/\1 

14 map read pysvnmanager-gitsvn = mirrors/pysvnmanager-gitsvn 

15 map read ossxp/redmine-* = ossxp/(redmine-.*):ossxp/redmine/\1 

16 map read ossxp/testlink-* = ossxp/(testlink-.*):ossxp/testlink/\1 
17 map read ossxp/docbones* = ossxp/(docbones.*):ossxp/docutils/\1 
18 repositories = /gitroot 





在 上 面 的 示例 中 ， 演 示 了 授权 指令 及 Gitosis 特 色 的 map 指 令 。 
- 第 1 行 ， 定 义 了 用 户 组 @ossxp-admin。 


` 第 2 行 ， 设 定 该 用 户 组 包含 用 户 jiangxin 及 用 户 组 @gitosis-admin 的 
所 有 用 户 。 


` 第 3 行 ， 设 定 该 用 户 组 具有 创建 及 读 写 与 通配符 ossxp/ 准 匹配 的 版 
本 库 的 权限 。 








两 个 星 号 匹配 任意 字符 ， 包 括 路 径 分 隅 符 〈“/) 。 此 功能 属于 笔者 
扩展 的 功能 。 


第 4 行 ， 设 定 该 用 户 组 可 以 只 读 访 问 gistote/# 匹 配 的 版 本 库 。 





一 个 星 号 匹配 任意 字符 ， 路 径 分 隔 符 〈/) 除外 。 此 功能 也 属于 笔 
者 扩展 的 功能 。 





. 第 5 行 ， 是 Gitosis 特 有 的 版 本 库 名 称 重 定位 功能 。 


即 对 redmine-* 匹 配 的 版 本 库 ， 经 过 名 称 重 定 位 ， 在 名 称 前 面 加 上 





ossxp/remdine。 其 中 \1 代 表 匹 配 的 整个 版 本 库 名 称 。 








用 户 组 @ossxp-admin 的 用 户 对 于 重 定 位 后 的 版 本 库 具 有 admin 〈 创 
建 和 读 写 ) 的 权限 。 


` 第 6 行 ， 是 我 扩展 的 版 本 库 名称 重 定位 功能 ， 支 持 正则 表达 式 。 


等 号 左边 的 名 称 进行 通配符 匹配 ， 匹 配 后 ， 再 经 过 右 侧 的 一 对 正则 
表达 式 进行 转换 《冒号 前 的 用 于 匹配 ， 冒 号 后 的 用 于 蔡 换 ) 。 











` 第 10 行 ， 使 用 了 内 置 的 @all 用 户 组 ， 因 此 不 需要 通过 members 设 
定 用 户 ， 因 为 所 有 用 户 均 属 于 该 用 户 组 。 


` 第 11 行 ， 设 定 所 有 用 户 均 可 以 只 读 访 问 ossxp/** 匹 配 的 版 本 库 。 

“ 第 12~17 行 ， 对 特定 路 径 进行 映射 ， 并 分 配 只 读 权限 。 

. 第 18 行 ， 设 置 版 本 库 的 根 路 径 为 /gitroot， 而 非 默认 的 版 本 库 根 路 
径 。 


31.3.4 ”Gitweb 整 合 


Gitosis 和 Gitweb 的 整合 提供 了 两 个 方面 的 内 容 。 一 个 是 可 以 设置 版 
本 库 的 描述 信息 ， 用 于 在 Gitweb 的 项 目 列表 页 面 中 显示 。 男 外 一 个 是 自 
动 生成 项 目的 列表 文件 供 Gitweb 参 考 ， 避 免 Gitweb 使 用 低 效 率 的 目录 递 





归 搜 索 查 找 Git 版 本 库 列 表 。 


例如 在 gitosis.conf 中 ， 下 面 的 配置 用 于 对 redmine-1.0.x 版 本 库 的 


Gitweb 整 合 进 行 设置 。 





1 [repo ossxp/redmine/redmine-1.0.x] 

2 gitweb = yes 

3 owner = Jiang Xin 

4 description = Redmine 1.0.x 群英 汇 定制 开发 























第 1 行 ，tepo 小 节 设 定 版 本 库 的 路 径 。 


版 本 库 的 实际 路 径 是 用 版 本 库 默 认 的 根 ( 即 在 [gitosis] 小 市 中 定义 
的 或 默认 的 ) 加 上 此 小 节 中 的 版 本 库 路 径 组 合 而 成 的 。 
第 2 行 ， 启 用 Gitweb 整 合 。 如 果 省 略 ， 使 用 全 局 [gitosis] 小 节 中 
Gitweb 的 设置 。 
` 第 3 行 ， 用 于 设置 版 本 库 的 属 主 。 
第 4 行 ， 用 于 设置 版 本 库 的 描述 信息 ， 显 示 在 Gitweb 的 版 本 库 列 


表 中 。 


每 一 个 repo 小 节 所 指 问 的 版 本 库 ， 如 果 局 用 了 Gitweb 选 项 ， 则 版 本 
库 名 称 汇总 到 一 个 项 目 列表 文件 中 。 访 项目 列表 文件 默认 保存 在 


~/gitosis/projects.list 中 。 





31.4 创建 新 版 本 库 





Gitosis 维 护 的 版 本 库 位 于 安装 用 户主 目录 下 的 repositories 目 录 中 ， 
即 如 果 安 闭 用 户 为 git， 则 上 厂 本 库 都 创建 在 home/git/repositories 目 录 之 
下 。 可 以 通过 配置 文件 gitosis.conf 修 改 默 认 的 版 本 库 的 根 路 径 。 


可 以 直接 在 服务 器 端 创建， 或 者 在 客户 端 远 程 创 建 版 本 库 。 





在 客户 端 远程 创建 版 本 库 时 ，Gitosis 的 原始 实现 是 这 样 的 : 对 版 本 
库 上 共有 writable 读 写 ) 权限 的 用 户 ， 当 对 一 个 不 存在 的 版 本 库 执行 殉 
隆 操作 时 会 自动 创建 版 本 库 ， 克 隆 即 创建 。 但 是 我 认为 这 不 是 一 个 好 的 
实践 ， 会 经 常 因 为 在 克 隆 时 把 URL 写 错 ， 从 而 导致 在 服务 器 痹 创建 垃圾 
版 本 库 。 笔 者 改进 的 实现 如 下 : 


` 增加 了 名 为 admin (或 init) 的 授权 指令 ， 只 有 具有 此 授权 的 用 
户 ， 才 能 够 创建 版 本 库 。 


. 只 具有 wrtitable (或 wtite) 权限 的 用 户 ， 不 能 在 服务 器 上 创建 版 本 


` 不 是 通过 克隆 创建 版 本 库 ， 而 是 在 对 版 本 库 进 行 推送 的 时 候 创 
建 。 当 克隆 一 个 不 存在 的 版 本 库 时 会 报错 退出 。 


远程 在 服务 器 上 创建 版 本 库 的 方法 如 下 : 


(1) 首先 本 地 建 库 。 





$ mkdir somerepo 

$ cd somerepo 

$ git init 

$ git commit --allow-empty 





(2) 使 用 git remote 指 令 添加 远程 版 本 库 。 





$ git remote add origin git@server:ossxp/somerepo.git 





(3) 运行 git push 完 成 在 服务 器 病 版 本 库 的 创建 。 





$ git push origin master 





31.5 轻 量 级 管理 的 Git 服 务 





轻 量 级 管理 的 含义 是 不 采用 默认 的 稍 嫌 复 杂 的 管理 模式 《远程 元 隆 
gitosis-admin 库 ， 修 改 并 推送 的 管理 模式 ) ， 而 是 直接 在 服务 器 端 通过 
预先 定制 的 配置 文件 提供 Git 服 务 。 这 种 轻 量 级 管理 模式 ， 对 于 为 某 些 
应 用 建立 快速 的 Git 库 服务 提供 了 便利 。 














例如 在 使 用 备份 工具 Gistore 进 行文 件 备份 时 ， 可 以 用 Gitosis 架 设 轻 
量 级 的 Git 服 务 ， 可 以 在 远程 使 用 Git 命 令 进 行 双 机 甚至 是 异地 备份 。 








首先 创建 一 个 专用 账号 ， 并 设置 该 用 户 只 能 执行 gitosis-serve 命 令 。 
例如 创建 账号 gistore， 通 过 修改 /etc/ssh/sshd_config 配 置 文件 ， 实 现 限制 


该 账号 登录 的 可 执行 命令 。 








Match user gistore 
ForceCommand gitosis-serve gistore 
X11iForwarding no 
AllowTcpForwarding no 
AllowAgentForwarding no 
PubkeyAuthentication yes 
#PasswordAuthentication no 





上 述 配置 信息 告诉 SSH 服 务 器 ， 几 是 以 gistore 用 户 登 录 的 账号 ， 都 


将 强制 执行 Gitosis 的 命令 : gitosis-serve gistore。 





然后 ， 在 该 用 户 的 主 目录 下 创建 一 个 配置 文件 .gitosis.conf (注意 文 
件 名 前 面 的 点 号 ) ， 如 下 : 


一 


[gitosis] 

repositories = /etc/gistore/tasks 
gitweb = yes 

daemon = no 

[group gistorel] 

members = gistore 

map readonly * = (.*):\1i/repo 





上 述 配 置 的 含义 是 : 
* 只 有 用 户 gistore 才 能 够 访问 /etc/gistore/tasks 下 的 Git 库 。 


` 版 本 库 的 名 称 需 要 变换 ， 例 如 system 库 会 变换 为 实际 路 


径 /etc/gistore/tasks/system/repo.gito 


第 32 章 ”Gerrit 代 人 码 审核 服务 器 


谷歌 Android 开 源 项 目 在 Git 的 使 用 上 有 两 个 重要 的 创新 ， 一 个 是 为 
多 版 本 库 协 同 而 引入 的 rapo， 这 在 前 面 第 25 章 已 经 详细 讨论 过 。 另 外 一 
个 重要 的 创新 就 是 Gerrit 一 一 代码 审核 服务 器 。Gerrit 为 Git 引 入 的 代码 审 
核 是 强制 性 的 ， 也 就 是 说 除非 特别 的 授权 设置 ， 向 Git 版 本 库 的 推送 必 
须要 经 过 Gerrit 服 务 器 ， 修 订 必 须 经 过 代码 审核 的 一 套 工作 流 之 后 ， 才 
可 能 经 批准 并 纳入 正式 代码 库 中 。 





首先 贡献 者 的 代码 通过 git 命 令 〈 或 repo 封 装 ) 推送 到 Gerrit 管 理 下 
的 Git 版 本 库 ， 推 送 的 提交 转化 为 一 个 一 个 的 代码 审核 任务 ， 审 核 任务 
可 以 通过 refs/changes/ 下 的 引用 访问 到 。 代 码 审核 者 可 以 通过 Web 界 面 查 
看 审核 任务 、 代 码 变 更 ， 通 过 Web 界 面 做 出 通过 代码 审核 或 打 回 等 决 

定 。 测 试 者 也 可 以 通 ee 
测试 ， 如 果 测试 通过 就 可 以 将 该 评审 任务 设置 为 校 验 通过 (verified) 。 
最 后 经 过 了 审核 和 校 验 的 修订 可 以 通过 Gerrit 界 面 中 的 提交 动作 合并 到 
版 本 库 对 应 的 分 文中 。 


Android 项 目 网 站 上 有 一 个 代码 贡献 流程 图 上 ， 详 细 地 介绍 了 Gerrit 
代码 审核 服务 器 的 工作 流程 。 翻 译 后 的 工作 流程 图 如 图 32-1。 


[1] http:/ /source.android.com/source/life-of-a-patch.html 


32.1 ”Gerrit 的 实现 原理 


Gerrit 更 准确 地 说 应 该 称 为 Gerrit2。 因 为 Android 项 目 最 早 使 用 的 评 
审 服务 器 Gerrit 不 是 今天 这 个 样子 的 。 最 早 版 本 的 Gerrit 是 用 Python 开 发 
运行 于 Google App Engine 上 的 ， 从 Python 之 父 Guido van Rossum 开 发 的 





Rietveld 分 支 而 来 。 在 这 里 要 讨论 的 Gerrit 实 为 Gerrit2， 是 用 Java 语 言 实 
现 的 叫 。 


1.SSH 协 议 的 Git 服 务 器 


Gerrit 本 身 基于 SSH 协 议 实 现 了 一 套 Git 服 务 器 ， 这 样 就 可 以 对 Git 数 
据 推送 进行 更 为 精确 的 控制 ， 为 强制 审核 的 实现 建立 了 基础 。 


Gerrit 提 供 的 Git 服 务 的 端口 并 非 标准 的 22 问 口 ， 默 认 是 29418 端 口 。 
这 个 端口 是 可 以 被 发 现 的 ， 当 访问 Gerrit 的 Web 界 面 时 可 以 得 到 这 个 端 
口 。 对 Android 项 目的 代码 审核 服务 器 ， 访 问 
https://review.source.android.com/ssh_info 就 可 以 查看 到 Git 服 务 的 服务 器 
域名 和 开放 的 端口 。 下 面 用 cunl 命 令 人 查看 网 页 的 输出 。 





$ curl -L -k http://review.source.android,.com/ssh_info 
review,.source.android.com 29418 
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摘自 : http://source.android.com/source/life-of-a-patch.html 


图 32-1 ” Gerrit 代码 审 核 工作 流 


2. 特 殊 引 用 refs/for 和 refs/changes 





Gerrit 的 Git 服 务 器 ， 禁 止 用 户 向 refsheads 命 名 空间 下 的 引用 执行 推 
送 《〈《 除 非特 别 的 授权 ) ， 即 不 允许 用 户 直接 向 分 支 进行 提交 。 为 了 让 开 
发 者 能 够 向 Git 服 务 器 提交 修订 ，Gerrit 的 Git 服 务 器 只 允许 用 户 向 特殊 的 
引用 refs/for/<branch-name> 下 执行 推送 ， 其 中 <branch-name> 即 为 开发 者 
的 工作 分 支 。 向 refs/for/<branch-name> 命 名 空间 下 推送 并 不 会 在 其 中 创 
建 引用 ， 而 是 为 新 的 提交 分 配 一 个 ID， 称 为 review-id， 并 为 该 review-id 
的 访问 建立 如 下 格式 的 引用 refs/changes/nn/<review-id>/m， 其 中 : 





" feview-id 是 Gerrit 为 评审 任务 顺序 而 分 配 的 全 局 唯一 的 号 码 。 


.nb 为 tfeview-id 的 后 两 位 数 ， 位 数 不 足 用 零 补 齐 。 即 hb 为 teview-id 除 
以 100 的 余数 。 


. mm 为 修订 号 ， 该 teview-id 的 首次 提交 修订 号 为 1， 如 果 该 修订 被 打 


回 ， 重 新 提交 修订 号 会 自 增 。 
3.Git 库 的 钩子 脚本 hooks/commit-msg 


为 了 保证 已 经 提交 审核 的 修订 通过 审核 入 库 后 ， 如 宋 被 别 的 分 文 拒 
选 《cherry-pick) 后 再 推送 至 服务 器 时 不 会 产生 新 的 重复 的 评审 任务 ， 
Gerrit 设 计 了 一 套 特 殊 的 方法 ， 即 要 求 每 个 提交 在 提交 说 明 中 包含 
Change-Id 键 值 对 作为 标签 ， 该 标签 在 首次 生成 时 使 用 特殊 的 哈 希 算法 





以 保障 其 唯一 性 。 执 行 拒 选 操作 时 ， 提 交 说 明 会 被 保持 ， 即 来 自 原始 提 
交 说 明 中 的 Change-Id 键 值 对 也 会 保持 不 变 ， 这 样 当 新 提交 推送 到 Gerrit 
服务 器 时 ，Gerrit 会 发 现 新 的 提交 包含 了 已 经 处 理 过 的 Change-Id， 吏 不 
再 为 该 修订 创建 新 的 评审 任务 和 review-id， 而 直接 将 提交 入 库 





为 了 使 得 Git 提 交 中 包含 唯一 的 Change-Id，Gerrit 提 供 了 一 个 钩子 脚 
本 ， 将 该 脚本 拷贝 到 开发 者 的 本 地 Git 库 的 钓 子 脚本 目录 中 ， 即 脚本 文 
件 .git/hooks/commit-msg。 这 个 钧 子 脚 本 在 用 户 提 交 时 ， 自 动 在 提交 说 
明 中 创建 Change-Id 键 值 对 。 至 于 如 何 实现 Change-Id 值 的 唯一 性 ， 可 以 
参考 该 脚本 。 














当 Gerrit 获 取 到 用 户 向 refs/for/<branch-name> 推 送 的 提交 中 包 
含 “Change-Id:I...” 的 格式 时 ， 如 果 该 Change-Id 之 前 没有 见 过 ， 会 创建 一 
个 新 的 评审 任务 并 分 配 新 的 review-id， 并 在 Gerrit 的 数据 库 中 保存 
Change-Id 和 review-id 的 关联 。 


如 果 用 户 的 提交 因为 菜 种 原因 被 打 回 重 做 ， 开 发 者 修改 之 后 重新 推 
送 到 Gerrit 时 就 要 注意 在 提交 说 明 中 使 用 相同 的 Change-Id (使 用 --amend 
提交 即 可 保持 提交 说 明 〉， 以 免 创 建新 的 评审 任务 。 还 要 在 推送 时 将 当 
前 分 支 推送 到 refs/changes/<nn>/<review-id>/<m> 中 ， 是 为 该 评审 任务 的 
一 个 新 的 修订 ， 其 中 <nn> 和 <review-id> 和 之 前 提交 的 评审 任务 的 修订 号 


相同 ，<m> 则 要 人 工 选 择 一 个 新 的 修订 号 。 





以 上 说 起 来 很 复杂 ， 但 是 在 实际 操作 中 只 要 使 用 repo 这 一 工具 ， 整 
相对 容易 多 了 。 


4. 其 余 一 切 交 给 Web 


Gerrit 另 外 一 个 重要 的 组 件 就 是 Web 服务 器 ， 通 过 Web 服 务 器 实现 对 
整个 评审 工作 流 的 控制 。 关 于 Gerrit 工 作 流 ， 请 参见 本 章 开 头 出 现 的 
Gerrit 工 作 流 程 图 。 


想 要 感受 一 下 Gerrit 的 魅力 ? 请 直接 访问 Android 项 目的 Gerrit 网 
站 : https://review.source.android.com/ ， 您 会 看 到 如 图 32-2 的 界面 。 





_AI | Documentation | Register| Sign In 
Open Merged Abandoned status:merged Search 
aND301D 


Search for status:merged 


























ip Subyect Owner Project Branch Updated V R 
» I76d?7fcf7 ARM. tegra_usb_phy._ Correct tm power off sequence Benoit Goby kemeliiegra lInux-tegra-2.6.36 905AM v vv 
(MERGED) 
f Add transient visibility m for empty containers Na ee 838AM v v 
Tbf3ec6ad (MERGED Tor Norbye platform/sdk Taste 
IILeel28e0 FixADT ild wiih the na， 0 | G Xavier h latform/s dk master 821AM Y v 
Ice6324c0 New layoutlib APL (MERGED)} Xavier Ducrohet platform/sdk master 807AM v v 
ARM. tegra_ dfs Fix dvfs disable config option ” 
If976cc25 (MERGED Colin Cross kernel/tiegra Inux-tegra-26.36 754AM Y v 
TI0496cf37 M.- tegr SS Add lock to ¢ yg (MER' Colin Cross kemellegra linux-tegra-26 36 TA3AM ¥ 
Te3a3cc8 人 RE Colin Cross kermnelnegra inux-teogra-26 .35 707 AM YY v 
ARM- tegra_ dfs Add config options to disable dfs f 
Cro inec “ 
I401ab558 MERGED Colin Cross kemnel/iegra linux-tegra-26.36 707 AM Y v 








Fix getDeviceldentity and getlmeiSv for 全 521f9 
JI643375c3 modules_ (MERGED) 


Johan Lindstrom pilatform/vendor/st-ericsson/u300 ericsson-mbm-devices 653AM v YY 








Iffos73dc ULE ceanuo emplyfunetions inmac/bh Etk Giling ~ kemelheora lnuxsteora2636 605AM w v 
Tadas7aang adeo- add short video mode decode to fbmon Erb Cilinn Varnalhanra liniv-tanra. 7 FE SNEAM ww ww 





图 32-2 ” Android 项 目 代码 审核 网 站 





点 击 沫 单 中 的 “Merged" 即 可 显示 已 经 通过 评审 且 合并 到 代码 库 中 的 


审核 任务 。 图 32-3 中 显示 的 就 是 Andorid 一 个 已 经 合并 到 代码 库 中 的 历史 
评审 任务 。 


eTLELT TE UE ET TT TTL vlsl-x) 
文件 (E) 编辑 (E) 查看 (VY) 历史 (S) 书签 (8) 工具 代 ) 必 助 (H) 

| EPE http: lreview.source.android com/#change,16993 

+ 








FF CC 


~ (1 1 - l | 
hd md dl db bd by 


和 


Change I51bcb5b3: Handle instrumentation time output that contains a bracket. 


Dhanaesie IS1bcbSb3asats20025619b0b e0457969104b17e 加 Handle instrumentation time output that contains a bracket. 
Owner Bret Chabot 
Froject platform/sdk Bug 2975380 
Branch master 
Topic Change-Id: I5lbcb5b3aaaf320b25619b0b8b4679691c4bff7e 
Uploaced Sep 4,2010 3:57 AM 
Updated Sep 6, 2010 6225 AM 
Status Merged 


Permalink 加 


Reviewer Veriied Coce Review 
Brett Chabot W Verifed 


Omari Stephens *1 Looks goo0d to me, but someone else must approve 
Xavier Ducrohet Looks good to me, approved 








> Included in 

> Dependencies 

> Patch Set 1 Sfble79b011665192f11c5509c5106ab023d (qitweb) 
了 patch Set 2 d342e5b41{07c0202bc2Be2bfi745b7c86d5a7 (gitweb) 


Author BrettChabot<brettchabot@android com> Sep 4, 2010 3:56 AM 
Commiter BrettChabot «brettchabot@android.com™~ Sep 4,2010 3:58 AM 


Dead repo download | checkout | pull | cherry-pick | patch 
ns repo download platform/sdk 16993/2 国 
i+ 


完成 














图 32-3 ”Android 项 目的 16993 号 评审 
从 图 32-3 中 可 以 看 出 : 
" URL 中 显示 的 评审 任务 编号 为 16993。 


该 评审 任务 的 Change-Ild 以 字母 I 开头 ， 包 含 了 一 个 唯一 的 40 位 


SHA1 哈 希 值 。 


人 进行 了 代码 审核 。 
. 该 评审 任务 的 状态 为 已 合并 : “merged”。 
. 该 评审 任务 总 共 包 含 两 个 补丁 集 : Patch set 1 和 Patch set 2。 
. 补丁 集 的 下 载 方法 是 : repo download platform/sdk 16993/2。 


如 果 使 用 repo 命 令 获 取 补 丁 集 是 非常 方便 的 ， 因 为 封装 后 的 repo 屏 
蔽 掉 了 Gerrit 的 一 些 实现 细 节 ， 例 如 补丁 集 在 Git 库 中 的 存在 位 置 。 如 前 
所 述 ， 补 丁 集 实际 保存 在 refs/changes 命 名 空间 下 。 使 用 git ls-remote 命 
令 ， 从 Gerrit 维 护 的 代码 库 中 可 以 看 到 补丁 集 对 应 的 引用 名 称 。 








$ git ls-remote \ 
ssh://review.source.android,.com:29418/platform/sdk \ 
refs/changes/93/16993* 
5fb1e79b01166f5192f11c5f509cf51f06ab023d refs/changes/93/16993/1 
d342ef5b41f07c0202bc26e2bfff745b7c86d5a7 refs/changes/93/16993/2 





接 下 来 就 来 介绍 一 下 Gerrit 服 务 器 的 部 署 和 使 用 方法 。 


[1] http://code.google.com/p/gerrit/ wiki/Background 


32.2 ”架设 Gerrit 的 服务 器 


1. 下 载 war 包 


Gerrit 是 由 Java 开 发 的 ， 被 封闭 为 一 个 war 包 : gerrit.war， 安 装 非 常 
简洁 。 如 果 需 要 从 源码 编译 出 war 包 ， 可 以 参照 相关 文档 加 。 不 过 最 简 
单 的 就 是 从 Google Code 上 直接 下 载 编译 好 的 war 包 。 





从 下 面 的 地 址 下 载 Gerrit 的 war 
包 : http://code.google.com/p/gerrit/downloads/list 。 在 下 载 页 面 会 有 一 个 
文件 名 类 似 Gerrit-x.x.x.war 的 war 包 ， 这 个 文件 就 是 Gerrit 的 全 部 。 示 例 
中 使 用 的 是 2.1.5.1 版 本 ， 把 下 载 的 Gerrit-2.1.5.1.war 包 重 命名 为 
Gerrit.war。 下 面 的 介绍 就 是 基于 这 个 版 本 。 





2. 数 据 库 选择 








Gerrit 需 要 数据 库 来 维护 账户 信息 和 跟踪 评审 任务 等 。 目 前 支持 的 
数据 库 类 型 有 PostgreSQL、MySQL 及 髓 入 式 的 H2 数 据 库 。 


选择 使 用 默认 的 H2 内 置 数据 库 是 最 简单 的 ， 因 为 这 样 无 须 任何 设 
置 。 如 果 想 使 用 更 为 熟悉 的 PostgreSQL 或 MySQL， 则 需要 预先 建立 数据 
库 。 


对 于 PostgreSQL， 在 数据 库 中 创建 一 个 用 户 gerrit， 并 创建 一 个 数据 
库 reviewdb。 





createuser -A -D -P -E gerrit 
createdb -E UTF-8 -0 gerrit reviewdb 





对 于 MySQL， 在 数据 库 中 创建 一 个 用 户 gerrit 并 为 其 设置 口令 (不 
要 真如 下 面 那 样 将 口令 设置 为 “secret”) ， 并 创建 一 个 数据 库 reviewdb。 





$ mysql -u root -p 

mysql> CREATE USER 'gerrit'@'localhost' IDENTIFIED BY "Secret '， 
mysql> CREATE DATABASE reviewdb; 

mysql> ALTER DATABASE reviewdb charset=Jatinl' 

mysql> GRANT ALL ON reviewdb.* TO 'gerrit'@'localhost'; 

mysql> FLUSH PRIVILEGES,; 








3. 以 一 个 专用 用 刻 账 号 执行 安 污 


在 系统 中 创建 一 个 专用 的 用 户 账号 如 : gerrit。 以 该 用 户 身 份 执行 安 
装 ， 将 Gerrit 的 配置 文件 、 内 置 数 据 库 、war 包 等 都 自动 安装 在 该 用 户主 
目录 下 的 特定 目录 中 。 





$ sudo adduser gerrit 

$ sudo su gerrit 

$ cd ~gerrit 

$ java -jar gerrit.war init -d review site 








在 安装 过 程 中 会 提出 一 系列 问题 。 


(1) 创建 相关 目录 。 


默认 Grerit 在 安装 用 户主 目录 下 创建 review_site， 并 把 相关 文件 安装 
在 这 个 目录 之 下 。Git 厂 本 库 的 根 路 径 默认 位 于 此 目录 之 下 的 git 目 录 
中 。 








*** Gerrit Code Review 2.1.5.1 
类 类 


Create '/home/gerrit/review site' [Y/n]? 
*** Git Repositories 
* 


大 类 
Location of Git repositories [git]: 





(2) 选择 数据 库 类 型 。 


选择 H2 数 据 库 是 简单 的 选择 ， 无 须 额 外 的 配置 。 





*** SQL Database 
火光 


* 
Database server type [H2/?]: 





(3) 设置 Gerrit Web 界 面 认 证 的 类 型 。 


默认 为 openid， 即 使 用 任何 支持 OpenID 的 认证 源 ( 如 Google、 
Yahoo! ) 进行 喘 份 认证 。 此 模式 支持 用 户 自 建 账号 ， 用 户 通 过 OpenID 
认证 源 的 认证 后 ，Gerrit 会 自动 从 认证 源 获取 相关 属性 如 用 户 全 名 和 邮 
件 地 址 等 信息 创建 账号 。Android 项 目的 Gerrit 服 务 器 即 采用 此 认证 模 
式 ; 


如 果 有 可 用 的 LDAP 服 务 器 ， 那 么 ldap 或 ldap_bind 也 是 非常 好 的 认 
证 方式 ， 可 以 直接 使 用 LDAP 中 的 已 有 账号 进行 认证 ， 不 过 此 认证 方式 


下 Gerrit 的 自 建 账号 功能 是 关闭 的 。 此 安装 示例 选择 的 就 是 -DAP 认 证 方 
Fe 


HTTP 认 证 也 是 可 选 的 认证 方式 ， 此 认证 方式 需要 配置 Apache 的 反 
癌 代 理 ， 并 在 Apache 中 配置 Web 站 点 的 口令 认证 ， 通 过 口令 认证 后 
Gerrit 在 创建 账号 的 过 程 中 会 询问 用 户 的 邮件 地 址 并 发 送 确认 邮件 。 





*** User Authentication 
类 类 类 


Authentication method [OPENID/?]: ? 
Supported options are: 

openid 

http 

http_ldap 

ldap 

ldap_bind 

development_become_any_account 
Authentication method [OPENID/?]: ldap 
LDAP server [ldap://localhost]: 
LDAP username : 
Account BaseDN : dc=foo, dc=bar 
Group BaseDN [dc=foo, dc=bar]: 





(4) 发 送 邮 件 设置 。 


默认 使 用 本 机 的 SMTP 发 送 邮 件 。 





*** Email Delivery 
大 火 类 


SMTP server hostname [localhost]: 
SMTP server port [(default)]: 


SMTP encryption [NONE/?]: 
SMTP username : 





(5) Java 相 关 设 置 。 


使 用 OpenJava 和 Sun Java 均 可 。Gerrit 的 war 包 要 复制 到 


review_site/bin 目录 中 。 





*** Container Process 

大 类 类 

Run as [gerrit]: 

Java runtime [/usr/l1ib/jvm/java-6-sun-1.6.0.21/jrel]: 
Copy gerrit.war to /home/gerrit/review site/bin/gerrit.war [Y/n]? 
Copying gerrit.war to /home/gerrit/review site/bin/gerrit.war 





(6) SSH 服 务 相 关 设 置 。 


Gerrit 的 基于 SSH 协 议 的 Git 服 务 非 党 重要， 默认 的 端口 为 29418。 换 
成 其 他 端口 也 无 妨 ， 因 为 repo 可 以 自动 探测 到 该 端口 。 





*** SSH Daemon 

大 类 类 

Listen on address [*]: 

Listen on port [29418 ] : 

Gerrit Code Review is not shipped with Bouncy Castle Crypto v144 
If available, Gerrit can take advantage of features 
in the library, but will also function without it. 

Download and install it now [Y/Nn]? 


Downloading http://www.bouncycastle.org/download/bcprov-jdk16-144.jar ... OK 
Checksum bcprov-jdk16-144.jar OK 
Generating SSH host key ... rsa... dsa... done 





(7) HTTP 服 务 相 关 设 置 。 


默认 局 用 内 置 的 HITP 服 务 右 ， 端 口 为 8080， 如 果 该 端口 被 占用 
(如 Tomcat) ， 则 需要 更 换 为 其 他 端口 ， 否 则 服务 启动 失败 。 如 下 例 就 
换 成 了 8081 端 口 。 





*** HTTP Daemon 
火炎 火 

Behind reverse proxy [y/N]? y 
Proxy uses SSL (https://) [y/N]? y 
Subdirectory on proxy server [/]: /gerrit 
Listen on address [*] 


Listen on port [8081]: 
Canonical URL [https://localhost/gerrit]: 
Initialized /home/gerrit/review site 





4. 启 动 Gerrit 服 务 


Gerrit 服 务 正 确 安 装 后 ， 运 行 Gerrit 启 动 脚本 来 启动 Gerrit 服 务 。 





$ /home/gerrit/review site/bin/gerrit.sh start 
Starting Gerrit Code Review: OK 





服务 正确 启动 之 后 ， 会 看 到 Gerrit 服 务 打开 两 个 端口 ， 这 两 个 端口 
征 在 Gerrit 安 装 时 指定 的 。 您 的 输出 和 下 面 的 示例 可 能 略 有 不 同 。 








$ sudo netstat -ltnp | grep -i gerrit 


tcp 0 0 0.0.0.0:8081 0.0.0.0:* LISTEN 
26383/GerritCodeRev 
tcp 0 0 0.0.0.0:29418 0.0.0.0:* LISTEN 
26383/GerritCodeRev 





5. 设 置 Gerrit 服 务 开 机 上 自动 启动 


Gerrit 服 务 的 启动 脚本 支持 start、stop、restart 参 数 ， 可 以 作为 init 肚 
本 开机 上 自动 执行 。 





$ sudo ln -Snf \ 
/home/gerrit/review site/bin/gerrit.sh \ 
/etc/init.d/gerrit.sh 
$ sudo ln -snf ../init.d/gerrit.sh /etc/rc2.d/S90gerrit 
$ sudo ln -snf ../init.d/gerrit.sh /etc/rc3.d/S90gerrit 





服务 自动 启动 脚本 /etc/init.d/gerrit.sh 需 要 通 
过 /etc/default/gerritcodereview 提 供 一 些 默 认 的 配置 。 以 下 面 的 内 容 来 创 


建 访 文件。 


GERRIT_SITE=/home/gerrit/review site 
NO_START=0 


6.Gerrit 认 证 方式 的 选择 


如 打 是 开放 的 Gerrit 服 务 ， 使 用 OpenId 认 证 是 最 好 的 方法 ， 就 像 谷 
歌 Android 项 目的 代码 审核 服务 器 配置 的 那样 。 任 何人 只 要 在 可 以 作为 
OpenId 提 供 者 的 网 站 上 “如 Google、Yahool! 等 ) 拥有 账号 ， 就 可 以 直 
接 通 过 OpenId 注 册 ，Gerrit 会 在 用 户 登 录 OpenId 提 供 者 网 站 成 功 后 ， 自 
动 获取 〈 经 过 用 户 的 确认 ) 用 户 在 OpenId 提 供 者 站 点 上 的 部 分 注册 信息 

(如 用 户 全 名 或 邮件 地 址 ) 在 Gerrit 上 自动 为 用 户 创建 账号 。 





如 果 架 设 有 LDAP 服 务 器 ， 并 且 用 户 账 号 都 在 LDAP 中 进行 管理 ， 
那么 采用 LDAP 认 证 也 是 非常 好 的 方法 。 登 录 时 提供 的 用 户 名 和 口令 通 
过 LDAP 服 务 器 验证 之 后 ，Gemrrit 会 自动 从 LDAP 服 务 器 中 获取 相应 的 字 
段 属 性 为 用 户 创建 账号 。 因 为 创建 账号 的 用 户 全 名 和 邮件 地 址 来 自 于 
LDAP， 因 此 不 能 在 Gerrit 中 更 改 ， 但 是 用 户 可 以 注册 新 的 邮件 地 址 。 我 
在 配置 LDAP 认 证 时 过 到 了 一 个 问题 就 是 创建 账号 的 用 户 全 名 是 空 
的 ， 这 是 因为 没有 正确 设置 LDAP 的 相关 字段 。 如 果 LDAP 服 务 器 使 用 
的 是 OpenLDAP，Gerrit 会 从 displayName 字 上 段 获取 用 户 全 名 ， 如 果 使 用 
Active Directory 则 用 givenName 和 sn 字段 的 值 拼 接 形 成 用 户 全 名 。 














Gerrit 还 支持 使 用 HTTP 认 证 ， 这 种 认证 方式 需要 架设 Apache 反 向 代 
理 ， 在 Apache 中 配置 HTTP 认证 。 用 户 知 要 访问 Gerrit 网 站 ， 首 先 需要 通 
过 Apache 配 置 的 HTTP Basic Auth 认 证 ， 当 Gerrit 发 现 用 户 已 经 登录 后 ， 
会 要 求 用 户 确认 邮件 地 址 。 当 用 户 确 认 邮 件 地 址 后 ， 再 填写 其 他 必须 的 
字段 完成 账号 注册 。HTTP 认 证 方式 的 缺点 除了 在 口令 文件 管理 上 需要 
管理 员 手 工 维护 比较 麻烦 之 外 ， 还 有 一 个 缺点 就 是 用 户 一 旦 登录 成 功 
， 想 退出 登录 或 更 换 其 他 用 户 账号 登录 会 变 得 非常 腑 烦 ， 除 非 关 闭 浏 
览 器 。 关 于 用 户 切换 有 一 个 小 守门 : 例如 Gerrit 登 录 URL 
为 https://server/gerrit/login/ ， 则 用 浏览 器 访问 











bl 


https://nobody:wrongpass(@server/gerrit/login/ ， 即 用 错误 的 用 户 名 和 口令 
履 盖 抒 浏览 器 缓存 的 认证 用 户 名 和 口令 ， 这 样 就 可 以 重新 认证 了 。 








在 后 面 的 Gerrit 演 示 和 介绍 中 ， 为 了 设置 账号 的 方便 ， 使 用 了 HTTP 
认证 ， 因 此 下 面 再 介绍 一 下 HTTP 认 证 的 配置 方法 。 


7. 配 置 Apache 代 理 访问 Gerrit 


默认 Gerrit 的 Web 服 务 端 口 为 8080 或 8081， 通 过 Apache 的 反问 代理 
就 可 以 使 用 标准 的 80 (HTTP) 或 443 (HTTPS) 来 访问 Gerrit 的 Web 界 
面 。 





ProxyRequests Off 
ProxyVia Off 
ProxyPreserveHost On 
<Proxy *> 
Order deny, allow 
Allow from all 


</Proxy> 
ProxyPass /gerrit/ http://127.0.0.1:8081/gerrit/ 





如 果 要 配置 Gerrit 的 HITP 认 证 ， 则 还 需要 在 上 面 的 配置 中 插入 
HTTP Basic Auth 认 证 的 设置 。 





<Location /gerrit/login/> 

AuthType Basic 

AuthName "Gerrit Code Review" 

Require valid-user 

AuthUserFile /home/gerrit/review site/etc/gerrit.passwd 
</Location> 





在 上 面 的 配置 中 ， 指 定 了 口令 文件 的 位 
置 : /home/gerrit/review_site/etc/gerrit.passwd。 可 以 用 htpasswd 命 令 维 护 
六 日 令 文 件 4 





$ touch /home/gerrit/review site/etc/gerrit.passwd 

$ htpasswd -m /home/gerrit/review site/etc/gerrit.passwd jiangxin 
New password: 

Re-type new password: 

Adding password for user jiangxin 








至 此 为 止 ，Gerrit 服 务 安装 完成 。 在 正式 使 用 Gerrit 之 前 ， 先 来 研究 
一 下 Gerrit 的 配置 文件 ， 以 免 安 装 过 程 中 遗漏 或 因 错 误 的 设置 而 影响 使 
用 。 





[1] http:/ /gettit.googlecode.com/svn/documentation/2.1.5/dev-readme.html 


32.3 ”Gerrit 的 配置 文件 


Gerrit 的 配置 文件 保存 在 部 署 目录 下 的 etc/gerrit.conf 文 件 中 。 如 果 对 
安装 时 的 配置 不 满意 ， 可 以 手工 修改 配置 文件 ， 重 启 Gerrit 服 务 即 可 。 





全 部 采用 默认 配置 时 的 配置 文件 : 





[gerrit] 
basePath = git 
canonicalwebUyrl1 = http://localhost:8080/ 


[database] 

type = H2 

database = db/ReviewDB 
[auth] 

type = OPENID 
[sendemail] 

smtpServer = localhost 
[container] 

user = gerrit 

javaHome = /usr/lib/jvm/java-6-openjdk/jre 
[sshd] 

listenAddress = *:29418 
[httpd] 

listenUrl] = http://*:8080/ 
[cache] 


directory = cache 





如 果 采 用 LDAP 认 证 ， 下 面 的 配置 文件 片断 配置 了 一 个 支持 匿名 绑 





定 的 LDAP 服 务 器 配置 。 
[auth] 
type = LDAP 
[ldap] 


server = ldap://localhost 
accountBase = dc=foo, dc=bar 
groupBase = dc=foo, dc=bar 








如 果 采 用 MySQL 而 非 默认 的 H2 数 据 库 ， 下 面 的 配置 文件 显示 了 相 
关 配 置 。 





[database] 
type = MYSQL 
hostname = localhost 
database = reviewdb 
username = gerrit 





LDAP 绑 定 或 与 数据 库 连接 的 用 户口 令 保存 在 etc/secure.config 文 件 





[database] 
password = Secret 





下 面 的 配置 将 Web 服 务 架 设 在 Apache 反 回 代 理 的 后 面 。 





[httpd] 
listenUrl = proxy-https://*:8081/gerrit 





32.4 ”Gerrit 的 数据 库 访问 








之 所 以 要 对 数据 库 访问 多 说 几 句 ， 是 因为 在 Web 和 界面 往 往 无 法 配置 
对 Gerrit 的 一 些 设置 ， 需 要 直接 修改 数据 库 ， 而 大 部 分 用 户 在 安装 Gerrit 
时 都 会 选用 内 置 的 H2 数 据 库 ， 可 能 大 部 分 用 户 并 不 了 解 如 何 操作 H2 数 
气 库 。 








实际 上 无 论 选择 何 种 数据 库 ，Gerrit 都 提供 了 两 种 数据 库 操作 的 命 
令 行 接口 。 第 一 种 方法 是 在 服务 器 端 调 用 gerrit,war 包 中 的 命令 入 口 ， 另 
外 一 种 方法 是 远程 SSH 调 用 接口 。 


对 于 第 一 种 方法 ， 需 要 在 服务 器 端 执行 ， 而 且 如 果 使 用 的 是 H2 内 
置 数据 库 还 需要 先 将 Gerrit 服 务 停止 。 先 以 安装 用 户 的 身份 进入 Gerrit 者 
署 目录 下 ， 再 执行 命令 调用 gerrit.war 包 ， 如 下 : 





$ java -jar bin/gerrit.war gsql 

Welcome to Gerrit Code Review 2.1.5.1 

(H2 1.2.134 (2010-04-23)) 

Type '\h' for help. Type '\r' to clear the buffer. 
gerrit> 


当 出 现 “gerrit>” 提 示 符 时 ， 就 可 以 输入 SQL 语句 操作 数据 库 了 。 


第 一 种 方式 需要 登录 到 服务 器 上 ， 而 且 操 作 H2 数 据 库 时 还 要 预先 
停止 服务 ， 显 然 很 不 方便 。 但 是 这 种 方法 也 有 存在 的 必要 ， 束 是 不 需要 











认证 ， 尤 其 是 在 管理 员 账 号 尚未 建立 之 前 就 可 以 查看 和 更 改 数据 库 。 





当 在 Gerrit 上 注册 了 第 一 个 账号 时 ， 即 拥有 了 管理 员 账 号 ， 正 确 为 
该 账号 配置 公 钥 之 后 ， 就 可 以 访问 Gerrit 提 供 的 SSH 登 录 服 务 。Gerrit 的 
SSH 人 协议 提供 访问 数据 库 的 第 二 种 方法 。 下 和 面 的 命令 就 是 用 管理 员 公 钥 
登录 Gerrit 的 SSH 服 务 器 ， 操 作 数 据 库 。 虽 然 沽 示 用 的 是 本 机 地 址 
(Clocalhost) ， 但 是 操作 远程 服务 器 也 是 可 以 的 ， 只 要 拥有 管理 员 权 
限 。 





$ ssh -p 29418 user@host gerrit gsql 

Welcome to Gerrit Code Review 2.1.5.1 

(H2 1.2.134 (2010-04-23)) 

Type '\h' for help. Type '\r' to clear the buffer ， 
gerrit> 





运行 命令 gerrit gsql 连 接 Gerrit 的 SSH 服 务 。 当 连接 上 数据 库 管 理 接 
口 后 ， 便 出 现 “gerrit>” 提 示 符 ， 在 该 提示 符 下 可 以 输入 SQL 命 令 。 下 面 
的 示例 中 ， 使 用 的 数据 库 的 后 端 为 H2 内 置 数据 库 。 


可 以 输入 show tables 命 令 显 示 数 据 库 列表 。 





gerrit> Show tables; 
TABLE_NAME TABLE_SCHEMA 


ACCOUNTS PUBLIC 
ACCOUNT_AGREEMENTS PUBLIC 
ACCOUNT_DIFF_PREFERENCES PUBLIC 


| 
十 
| 
| 
| 
ACCOUNT_EXTERNAL_ITDS | PUBLIC 
| 
| 
| 
| 
| 
| 
| 


ACCOUNT_GROUPS PUBLIC 
ACCOUNT_GROUP_AGREEMENTS PUBLIC 
ACCOUNT_GROUP_MEMBERS PUBLIC 
ACCOUNT_GROUP_MEMBERS_AUDIT PUBLIC 
ACCOUNT_GROUP_NAMES PUBLIC 
ACCOUNT_PATCH_REVIEWS PUBLIC 
ACCOUNT_PROJECT_WATCHES PUBLIC 


ACCOUNT_SSH_KEYS | PUBLIC 
APPROVAL_CATEGORIES | PUBLIC 
APPROVAL_CATEGORY_VALUES | PUBLIC 
CHANGES | PUBLIC 
CHANGE_MESSAGES | PUBLIC 
CONTRIBUTOR_AGREEMENTS | PUBLIC 
PATCH_COMMENTS | PUBLIC 
PATCH_SETS | PUBLIC 
PATCH_SET_ANCESTORS | PUBLIC 
PATCH_SET_APPROVALS | PUBLIC 
PROJECTS | PUBLIC 
REF_RIGHTS | PUBLIC 
SCHEMA_VERSION | PUBLIC 
STARRED_CHANGES | PUBLIC 
SYSTEM_CONFIG | PUBLIC 
TRACKING_IDS | PUBLIC 


(27 rows; 65 ms) 





输入 show columns 命 令 显 示 数 据 库 的 表 结 构 。 





gerrit> show columns from system config; 


FIELD | TYPE | NULL | KEY | DEFAULT 
人 a 
REGISTER_EMAIL_PRIVATE_KEY | VARCHAR(36) | NO | | 
SITE_PATH | VARCHAR(255) | YES | | NULL 
ADMIN_GROUP_ID | INTEGER(10) | NO | | 9 
ANONYMOUS_GROUP_ID | INTEGER(10) | NO | | 9 
REGISTERED_GROUP_ID | INTEGER(10) | NO | | 9 
WILD_PROJECT_NAME | VARCHAR(255) | NO | pe 

BATCH_USERS_GROUP_ID | INTEGER(10) | NO | | 9 

SINGLETON | VARCHAR(1) | NO | PRI | ?5 


(8 rows; 52 ms) 





关于 H2 数 据 库 更 多 的 SQL 语法 ， 请 参 


考 : http:/www.h2database.com/html/grammar.html 。 


下 面 开始 介绍 Gerrit 的 使 用 。 


32.5 立即 注册 为 Gerrit 管 理 员 


第 一 个 Gerrit 账 户 自动 成 为 权限 最 高 的 管理 员 ， 因 此 Gerrit 安 装 完毕 
后 的 第 一 件 事 情 就 是 立即 注册 或 登录 ， 以 便 初 始 化 管理 员 账 号 。 下 面 的 
示例 是 在 本 机 (localhost〉 以 HTTP 认 证 方式 架设 的 Gerrit 审 核 服 务 器 。 
第 一 次 访问 的 时 候 会 弹出 非常 眼熟 的 HTTP Basic Auth 认 证 界面 ， 如 图 
32-4 所 示 。 








用 户 各 


密码 : 


四 取消 es 确定 





图 32-4 HTTIP Basic Auth 认 证 界面 


和 输入 正确 的 用 户 名 和 口令 登录 后 ， 系 统 目 动 创 建 ID 为 1000000 的 账 
写 ， 该 账号 是 第 一 个 注册 的 账号 ， 会 被 自动 赋予 定理 员 的 映 份 。 因 为 使 
用 的 是 HTTP 认 证 ， 用 户 的 邮件 地 址 等 个 人 信息 尚未 确定 ， 因 此 登录 后 
首先 进入 到 个 人 信息 设置 界面 ， 如 图 32-5。 








All | My | Admin | Documen tation 
Changes Drafts ”Watched Changes Starred Changes 








Welcome to Gerrit Code Review 


Please review your contact information: 
The following contact information was automatically obtained when you signed-in to the site. This 


information is used to display who you are to others, and to send updates to code reviews you have 
either started or subscribed to. 


Fu Name 


Preferred Emal Register New Email 


Save Changes 





图 32-5 ”Gerrit 第 一 次 登录 后 的 个 人 信息 设置 界面 


在 图 32-5 中 可 以 看 到 在 菜单 中 有 “Admin” 菜 单项 ， 说 明 当 前 登录 的 
用 户 被 赋予 了 管理 员 权 限 。 在 图 32-5 的 联系 方式 确认 对 话 框 中 有 一 个 注 
册 新 邮件 地 址 的 按钮 ， 点 击 该 按钮 弹出 邮件 地 址 录入 对 话 框 ， 如 图 32- 
6。 


Register Email Address 


Aconfirmation link will be sent by email to this address 


You must click on the link to complete the registration and make the address available for selection. 


|jiangxin@moon.ossxp.com 


Register Cancel 


图 32-6 输入 个 人 的 邮件 地 址 


必须 输入 一 个 有 效 的 邮件 地 址 以 便 能 够 收 到 确认 邮件 。 这 个 邮件 地 
址 非 第 重要 ， 因 为 Git 代 码 提交 时 ， 在 提交 说 明 中 出 现 的 邮件 地 址 需要 
和 这 个 地 址 一 致 。 填 写 了 邮件 地 址 后 会 收 到 一 封 确认 邮件 ， 点 击 邮 件 中 


的 确认 链接 会 重新 进入 到 Gerrit 账 号 设置 界面 ， 如 图 32-7。 


All | My | Admin | Documentation Anonymous Coward (1000000) | Setincs | Sign Out 
Changes Dratts Watched Changes Starred Changes hange ], trid, ow nail or r Ver y Search 


Fut Name |jiang Xin 
Preferences 
Watched Prolects Preferred Emai jiangxin@moon ossxp .com wv | Register New Email 


Contact Information 
Save Changes 
HTIP Password 
ldentities 
Groups 





图 32-7 邮件 地 址 确认 后 进入 Gettit 界 面 


在 Full Name 字 上段 输 入 用 户 名 ， 点 击 保存 更 改 后 ， 右 上 角 显 示 
的 “Anonymous Coward” 就 会 显示 为 用 户 登 录 的 姓名 和 邮件 地 址 。 





接 下 来 需要 做 的 最 重要 的 一 件 事 就 是 配置 公 铀 〈 如 图 32-8) 。 通 过 
该 公 钥 ， 注 册 用 户 可 以 通过 SSH 协 议 向 Gerrit 的 Git 服 务 器 提交 ， 如 果 具 
有 管理 员 权 限 还 能 够 远程 管理 Gerrit 服 务 器 。 


Al | My | Admin | Documentation Jiang Xin <jiangxin@moon.ossxp.com> 
Changes ”Dratts ‘WatchedChanges Starred Changes ri weref 





Add SSH Public Key 
(GitHub" iget SHK ) 
Contact Information 
SSH Public Keys 





Clear | Open Key Add 





图 32-8 Getrtit 的 SSH 公 钥 设 置 界面 


在 文本 框 中 粘贴 公 钥 。 关 于 如 何 生 成 和 管理 公 钥 ， 请 参见 “第 29 
章 ”使 用 SSH 人 协议 ”的 相关 内 容 。 


点 击 “Add” 按 钮 ， 完 成 公 钥 的 添加 。 添 加 的 公 钥 就 会 显示 在 列表 
中 ， 如 图 32-9。 一 个 用 户 可 以 添加 多 个 公 钥 。 
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Q3 | Sign Out 
Search 





Jiang Xin <jiangxin@moon.ossxp.com> | Se 











Preferences 口 ssh-rsa AAAAB3NzaClyc2EAAAABIwAAAQEAOC , , ,WZwhuL3Q== 医 jiangxin@ossxp 
Watched Proiects Add Key 

Contact Information 

SSH Public Keys Server Host Key 

HTTP Passwor d Fed pdnt 

ldentities 09:3b:c6:3c:35:50:ae:9f:44:be:04:4a:el:3d:9e:a0 


Entry for /. ssh/known_hosts 
[Vocalhost) :29418 ssh-rsa AAAAB3NzaClyc2EAAAADAQABAAAAgQC5 CSFGqSh+/sck . . .1QaVo5sbw== 出 








图 32-9 ”用 户 的 公 和 钥 列 表 


点 击 左 侧 的 “Groups”( 用 户 组 ) 菜单 项 ， 可 以 看 到 当前 用 户 所 属 的 
分 组 ， 如 图 32-10。 


All My Admin Documentation 
Changes Drafts Watched Changes Starred Changes Je # ,trid, ¢ er r Search 


Settings 


Group Name Description 

Administrators Gerrit Site Administrators 
Anonymous Users Any user, sigNed-in or not 
Registered Users Any soned-inuser 


Profile 
Preferences 
Watched Prolects 
Contact information 
SSH Public Keys 
HTTP Password 
Identities 

Groups 








图 32-10 Gerrit 用户 所 属 的 用 户 组 





第 一 个 注册 的 用 户 同时 属于 三 个 用 户 组 ， 一 个 是 管理 员 用 户 组 
(CAdministrators) ， 另 外 两 个 分 别 是 Anonymous Users (任何 用 户 ) 和 


Registered Users 〈 注 册 用 户 ) 


32.6 ”管理 员 访 问 SSH 的 管理 接口 


在 Gerrit 个 人 配置 界面 中 设置 了 公 钥 之 后 ， 就 可 以 连接 Gerrit 的 SSH 
服务 器 《默认 端口 29418) 执行 命令 ， 以 下 示例 中 Gerrit 服 务 器 的 地 址 为 
host， 用 户 ID 是 在 Gerrit 中 创建 的 管理 员 ID〈 如 gerrit) 。 如 果 SSH 命 令 的 
登录 ID 和 系统 登录 ID 相 同 ， 用 户 ID 可 以 省 略 。 


任何 用 户 都 可 以 通过 SSH 连 接 执行 gerrit ls-projects 命 令 查 看 项 目 列 
表 。 下 面 的 命令 没有 输出 ， 是 因为 项 目 尚 未 建立 。 








$ ssh -p 29418 gerrit@host gerrit ls-projects 





可 以 执行 scp 命 令 从 Gerrit 的 SSH 服 务 器 中 拷贝 文件 。 





$ scp -P 29418 -p -r gerrit@host:/ gerrit-files 
$ find gerrit-files -type f 
gerrit-files/bin/gerrit-cherry-pick 
gerrit-files/hooks/commit-msg 





可 以 看 出 Gerrit 服 务 器 提供 了 两 个 文件 可 以 通过 scp 下 载 ， 其 中 
commit-msg 脚 本 文件 应 该 放 在 用 户 本 地 Git 库 的 钩子 目录 中 以 便 在 生成 
的 提交 中 包含 唯一 的 Change-Id。 这 在 之 前 的 Gerrit 原 理 中 介绍 过 。 





除了 普通 用 户 可 以 执行 的 命令 外 ， 管 理 员 还 可 以 通过 SSH 连 接 执 行 
Gerrit 相 关 的 管理 命令 。 例 如 之 前 介绍 的 管理 数据 库 : 





$ ssh -p 29418 gerrit@host gerrit gsql 

Welcome to Gerrit Code Review 2.1.5.1 

(H2 1.2.134 (2010-04-23)) 

Type '\h' for help. Type '\r' to clear the buffer ， 
gerrit> 





此 外 管理 员 还 可 以 通过 SSH 连 接 执 行 账号 创建 ， 项 目 创建 等 管理 操 
作 ， 可 以 执行 下 面 的 命令 得 看 帮助 信息 。 





$ ssh -p 29418 gerrit@host gerrit --help 
gerrit COMMAND [ARG ...] [--] [--help (-h)] 
-- : end of options 
--help (-h) : display this help text 
Available commands of gerrit are: 
approve 
create-account 
create-group 
create-project 
flush-caches 
gsql 
ls-projects 
query 
receive-pack 
replicate 
review 
set-project-parent 
show-caches 
show-connections 
show-queue 
stream-events 
See 'gerrit COMMAND --help' for more information. 





更 多 的 帮助 信息 ， 还 可 以 参考 Gerrit 版 本 库 中 的 帮助 文件 : 


Documentation/cmd-index.html。 


32.7 ”创建 新 项 目 


一 个 Gerrit 项 目 对 应 于 一 个 同名 的 Git 库 ， 同 时 拥有 一 套 可 定制 的 评 
审 流程 。 创 建 一 个 新 的 Gerrit 项 目 束 会 在 对 应 的 版 本 库 根 目录 下 创建 Git 
库 。 管 理 员 可 以 使 用 命令 行 创建 新 项 目 。 








$ ssh -p 29418 gerrit@host gerrit create-project --name new/project 





执行 gerrit 1s-projects 命 令 可 以 看 到 新 项 目 已 经 成 功 创建 。 





$ ssh -p 29418 gerrit@host gerrit ls-projects 
new/project 





在 Gerrit 的 Web 管 理 界面 也 可 以 看 到 新 项 目 已 经 建立 ， 如 图 32-11。 


Al | My | Admin | Documentation Jiang Xin <jiangxin@moon.ossxp.com> | Settings | Sign Out 
区 HA ] | W UI i j ) IeW 


Groups Projects Search 


Projects 


Description 
Rights inherited by all other projects 





图 32-11 Getrrit 中 项 目 列表 


在 项 目 列 表 中 可 以 看 到 除了 新 建 的 new/project 项 目 之 外 还 有 一 个 名 
为 “--All Projects--” 的 项 目 ， 其 实 它 并 非 一 个 真实 存在 的 项 目 ， 只 是 为 了 
项 目 授 权 管理 的 方便 一 一 在 “--All Projects--” 中 建立 的 项 目 授权 能 够 被 其 


他 项 目 共 至 。 














在 服务 器 端 也 可 以 看 到 在 Gerrit 部 普 中 ， 版 本 库 根 目录 下 已 经 有 同 
名 的 Git 版 本 库 被 创建 。 





$ ls -d /home/gerrit/review site/git/new/project.git 
/home/gerrit/review site/git/new/project.git 





这 个 新 的 版 本 库 刚刚 初始 化 尚未 包括 任何 数据 。 是 否 可 以 通过 git 
push 问 该 版 本 库 推送 一 些 初 始 数 据 呢 ?” 下 面 用 Gerrit 的 SSH 协 议 克 隆 该 版 
本 库 ， 并 答 试 癌 其 推送 数据 。 





$ git clone ssh://gerrit@host:29418/new/project.git myproject 
Cloning into myproject... 
warning: You appear to have cloned an empty repository. 
$ cd myproject/ 
$ echo hello > readme.txt 
$ git add readme.txt 
$ git commit -m "initialized." 
[master (root-commit) 15a549b] initialized. 
1 files changed, 1 insertions(+), 0 deletions(-) 
create mode 100644 readme.txt 
$ git push origin master 
Counting objects: 3, done. 
Writing objects: 100% (3/3), 222 bytes, done. 
Total 3 (delta 0), reused 0 (delta 0) 
To ssh://gerrit@host:29418/new/project.git 
! [remote rejected] master -> master (prohibited by Gerrit) 
error: failed to push some refs to 'ssh://gerrit@host:29418/new/project.git'" 





间 Gerrit 的 Git 版 本 库 推送 失败 ， 远 程 Git 服 务 占 返回 错误 信 
尽 : “prohibited by Gerrit*。 这 是 因为 Gerrit 默 认 不 允许 直接 向 分 文 推 
送 ， 而 是 需要 向 refs/for/<branch-name> 的 特殊 引用 进行 推送 以 便 将 提交 
转换 为 评审 任务 。 


但 是 是 否 可 以 将 版 本 库 的 历史 提交 不 经 审核 ， 直 接 推送 到 Gerrit 维 





护 的 Git 版 本 库 中 呢 ? 是 的 ， 只 要 通过 Gerrit 的 管理 界面 为 该 项 目 授权 : 
允许 某 个 用 户 组 〈 如 Administrators 组 ) 的 用 户 可 以 直接 向 分 支 推送 。 
(注意 该 授权 在 推送 完毕 后 尽快 撤销 ， 以 免 被 滥用 。 








Gerrit 的 界面 对 用 户 非常 友好 《如 图 32-12) 。 例 如 在 添加 授权 的 界 
面 中 ， 只 要 在 用 户 组 的 输入 框 中 输入 前 几 个 字母 ， 就 会 弹出 用 户 组 列表 
以 供 选 择 。 


Al | My_|_ Admin_ | Documentation Jiang Xin <jiangxin@moon.ossxp.com> | Setinas | Sign Out 
Groups Proiects [ | er emal Search 


Project new/project 


General Homme Ne From 
[Qe 


AlIP 
Access Ri 
Cale0oryY QioUp Neme Reforeorce Name Permitted Renoe 
1 lwould prefer that you didn't submit this 
+1 lnnks onnt in ma, but snmennna olan MUSt ANnNMve 


Branches 
Acceos 
Code Review Reolsiered Users refs/heads/” 
Foroe Identity Reogistlered Users refsr” +1 Forge Author identiy 
口 Owner Administrators refs” +1 Administer Al| Settings 
Read Access Adrinistrators refs” +1 Read access 
Read Access Anonymous Users refs/” +1 Re $ 
Read Accesse Roeooistered User rofor” Uplo 让 rmlesior 


Delete 


Category Push Branch | 一 | 
Group Name [Adml 


Reference Name: | Administrators 


Permitted Range; *2; Create Branch "| 


Add Access Right 





图 32-12 ”添加 授权 的 界面 


添加 授权 完毕 后 ， 项 目 “new/project”* 的 授权 列表 就 会 出 现 新 增 的 为 
Administrators 管 理 员 添加 的 “+2:Create Branch” 授 权 ， 如 图 32-13。 


Al | My | Admin | Documentation | Jiang Xin <jiangxin@moon.ossxp.com> | Settings | Sign Out 
Groups Projects e #, SHA-] wner:emalil ewe 3 Search 


Project new/project 


General | Rights nherit From 
~ All Projects ~- 
Access Rights 
Category Group Name RAReference Name fermitied Range 
-1 1would prefer that you didnt submit this 
+1 Looks yood to me, but someone else must approve 
Forge ldentity Registered Users refsr +1 Forge Author ldentity 
口 Owner Adrministrators refs” +1 Administer All Settings 
口 Push Branch Administrators refsiheadsr +2: Creale Branch 
Read Access Administrators refs” + Read access 
Read Access Anonymous Users ef 六 +1 Read actess 
Read Access Registered Users refs” +2 Upload permission 


Branches 
ACCESS 


Coue Review Registered Users refsiheadsr” 





Delete 


Category Push Branch ”| 
Group Name 


Reference Name 
Permitted Range; +2: Create Branch ”| 


Add Access Right 





图 32-13 ”添加 授权 后 的 授权 列表 








因为 已 经 为 管理 员 分 配 了 直接 向 refs/heads/* 引 用 推送 的 授权 ， 这 样 
就 能 够 回 Git 版 本 库 推送 数据 了。 再 执行 一 次 推送 任务 看 看 能 否 成 功 。 








$ git push origin master 
Counting objects: 3, done. 
Writing objects: 100% (3/3), 222 bytes, done. 
Total 3 (delta 0), reused 0 (delta 0) 
To ssh://gerrit@host:29418/new/project .git 
! [remote rejected] master -> master (you are not committer jiangxin@ossxp.com) 
error: failed to push some refs to 'ssh://gerrit@host:29418/new/project.git'" 








推送 又 失败 了 ， 但 是 服务 器 端 返回 的 错误 信息 却 不 同 。 上 一 次 出 错 
返回 的 是 “prohibited by Gerrit”， 而 这 一 次 返回 的 错误 信息 是 “you are not 


committer” 


这 是 为 什么 呢 ? 看 看 提交 日 志 : 





$ git 1og --pretty=full 

commit 15a549bac6bd03ad36e643984fed554406480b2c 

Author: Jiang Xin <jiangxin@ossxp.com> 

Commit: Jiang Xin <jiangxin@ossxp.com> 
initialized. 





提交 者 Committer 为 “Jiang Xin<jiangxin@ossxp.com>”， 而 Gerrit 中 注 
册 的 用 户 的 邮件 地 址 是 “jiangxin@moon.ossxp.com”， 两 者 之 间 不 一 致 ， 
导致 Gerrit 再 一 次 拒绝 了 提交 。 如 果 再 到 Gerrit 中 看 一 下 new/project 的 权 
限 设置 ， 会 看 到 这 样 一 条 授权 : 





Category Group Name Reference Name Permitted Range 





Forge Identity Registered Users refs/* +1: Forge Author Identity 





这 条 授权 的 含义 是 : 提交 中 的 Author 字 段 不 进行 邮件 地 址 是 否 注册 
的 检查 ， 但 是 要 对 Commit 字 段 进 行 邮件 地 址 检查 。 如 果 增 加 一 个 更 高 
级 别 的 “Forge Identity” 授 权 ， 也 可 以 忽略 对 Committer 的 邮件 地 址 的 检 
查 ， 但 是 尽量 不 要 对 授权 进行 非 必须 的 改动 ， 因 为 在 提交 的 时 候 使 用 注 
册 的 邮件 地 址 是 一 个 非常 好 的 实践 。 











下 面 就 通过 git config 命 令 修改 提交 时 所 用 的 邮件 地 址 ， 和 Gerrit 注 
册 时 用 的 地 址 保持 一 致 。 然 后 用 --amend 参 数 重新 执行 提交 以 便 让 修改 
后 的 提交 者 邮件 地 址 在 提交 中 生效 。 





$ git config user ,email jiangxin@moon.ossxp.com 
$ git commit --amend -m initialized 
[master 82c8fc3] initialized 
Author: Jiang Xin <jiangxin@ossxp.com> 
1 files changed, 1 insertions(+), 0 deletions(-) 
create mode 100644 readme.txt 


$ git push origin master 
Counting objects: 3, done. 
Writing objects: 100% (3/3), 233 bytes, done. 
Total 3 (delta 0), reused 0 (delta 0) 
To ssh://gerrit@host:29418/new/project.git 
* [new branch] master -> master 








看 ， 这 次 提交 成 功 了 ! 之 所 以 成 功 ， 是 因为 提交 者 的 邮件 地 址 更 改 
了 。 看 看 重新 提交 的 日 志 ， 可 以 发 现 Author 和 Commit 的 邮件 地 址 不 同 ， 
而 Commit 字 段 的 邮件 地 址 和 注册 时 使 用 的 邮件 地 址 相同 。 





$ git 1og --pretty=full 

commit 82c8fc3805d57ccod17d58e1452e21428910fd2d 

Author: Jiang Xin <jiangxin@ossxp.com> 

Commit: Jiang Xin <jiangxin@moon.ossxp.com> 
initialized 





注意 ， 版 本 库 初 始 化 完成 之 后 ， 应 尽快 删除 为 项 目 新 增 的 “Push 
Branch” 类 型 的 授权 ， 对 新 的 提交 强制 使 用 Gerrit 的 评审 流程 。 


32.8 ”从 己 有 的 Git 库 创建 项 目 


如 果 已 经 拥有 很 多 版 本 库 ， 希 望 从 这 些 版 本 库 创 建 Gerrit 项 目 ， 如 
果 像 上 面 介绍 的 那样 一 个 一 个 地 创建 项 目 ， 再 执行 git push 命 令 推 送 已 经 
包含 历史 数据 的 版 本 库 ， 将 是 十 分 抹 烦 的 事情 。 那 么 有 没有 什么 简单 的 
办 法 呢 ? 可 以 通过 下 面 的 步骤 实现 多 项 目的 快速 创建 。 














首先 将 已 有 版 本 库 创 建 到 Gerrit 的 版 本 库 根 目录 下 。 注 意 版 本 库 名 
称 将 会 成 为 项 目 名 除去 .git 后 经) ， 而 且 创 建 ( 或 克隆 ) 的 版 本 库 应 
为 裸 版 本 库 ， 即 使 用 --bare 参 数 创建 。 





例如 在 Gerrit 的 Git 版 本 库 根 目录 下 创建 名 为 hello.git 的 版 本 库 。 下 面 
的 示例 中 我 偷 了 一 下 懒 ， 直 接 从 new/project 元 隆 到 hello.git。:) 





$ git clone --mirror \ 
/home/gerrit/review site/git/new/project.git \ 
/home/gerrit/review site/git/hello.git 





这 时 碍 看 版 本 库 列 表 ， 却 看 不 到 新 建立 的 名 为 hello.git 的 Git 库 出 现 
在 项 目 列表 中 。 


$ ssh -p 29418 gerrit@host gerrit ls-projects 
new/project 


可 以 通过 修改 Gerrit 数 据 库 来 注册 新 项 目 ， 即 连接 到 Gerrit 数 据 库 ， 


输入 SQL 插入 语句 。 





$ ssh -p 29418 gerrit@host gerrit gsql 
Welcome to Gerrit Code Review 2.1.5.1 
(H2 1.2.134 (2010-04-23)) 
Type '\h' for help. Type '\r' to clear the buffer ， 
gerrit> INSERT INTO projects 
-> (Use_contributor_ agreements ，Submit_type ，name ) 
-> VALUES 
-> ('N' ，'M' , 'hello'); 
UPDATE 1; 1 ms 
gerrit> 





注意 SQL 语 句 中 的 项 目 名 称 是 版 本 库 名 称 除去 .git 后 级 的 部 分 。 在 数 
据 库 插入 数据 后 ， 再 来 得 看 项 目 列表 惑 可 以 看 到 新 注册 的 项 目 了 。 





$ ssh -p 29418 gerrit@host gerrit ls-projects 
hello 
new/project 





可 以 登录 到 Gerrit 项 目 对 新 建立 的 项 目 进 行 相 关 设 置 。 例 如 修改 项 
目的 说 明 ， 项 目的 提交 和 策略， 是否 要 求 提 区 说 明 中 必须 包含 “Signed-off- 
by” 信 息 等 ， 如 图 32-14。 





Al | My | Admin | Documentation | Jiang Xin <jiangxin@moon.ossxp.com> | Settings | Sign Out 
Groups Projects ,SHA-1. wner | or reviey 


Search 


Project hello 


General |Description 
Branches 
Access 





Change Suhmit Arfinn 
Merge lf Necessary 全 
Contributor Agreements 
口 Reouire $1 gned-off- DY in commit message 





图 32-14 项 目 基 本 设置 


这 种 通过 修改 数据 库 从 已 有 版 本 库 创 建 项 目的 方法 适合 创建 大 批量 
的 项 目 。 下 面 就 对 新 建立 的 hello 进 行 一 次 完整 的 Gerrit 评 审 流程 。 


32.9 ”定义 评审 工作 流 

刚刚 安装 好 的 Gerrit 的 评审 工作 流 并 不 完整 ， 还 不 能 正常 地 开展 评 
审 工 作 ， 需 要 对 项 目 授 权 进 行 设置 以 定制 适合 的 评审 工作 流 。 

默认 安装 的 Gerrit 中 只 内 置 了 四 个 用 户 组 ， 如 表 32-1 所 示 。 


表 32-1 Gettit 内 置 用 户 组 


用 户 组 说 明 

Administrators Gerrit 管理 员 

Anonymous Users 任何 用 户 ， 登 录 或 未 登录 
Non-Interactive Users Gerrit 中 执行 批 处 理 的 用 户 
Registered Users 任何 登录 用 户 





未 登录 的 用 户 只 属于 Anonymous Users， 登 录用 户 则 同时 拥有 
Anonymous Users 和 Registered Users 的 权限 。 对 于 管理 员 则 还 拥有 





Administrators 用 户 组 权限 。 


查看 全 局 〈( 伪 项 目 “--All Projects--”) 的 初始 权限 设置 ， 会 看 到 如 表 
32-2 一 样 的 授权 表格 。 


表 32-2 Gettit 授 权 表 格 


用 户 组 名 称 


引用 名 称 


权限 范围 





1 Code Review 
2 Forge Identity 
3 Read Access 
4 Read Access 
5 Read Access 


对 此 表格 中 的 授权 解读 如 下 : 


` 对 于 匿名 用 户 : 根据 第 4 条 授权 策略 ， 


本 库 。 


Registered Users 


Registered Users 
Administrators 
Anonymous Users 


Registered Users 


refs/heads/* 


refs/* 
refs/* 


refs/* 


refs/* 


-1: I would prefer that you didn’t submit this 
+1: Looks good to me, but someone else 
must approve 


+1: Forge Author Identity 
十 1: Read access 
十 1: Read access 


+2: Upload permission 


匿名 用 户 能 够 读 取 任意 版 


“ 对 于 注册 用 户 : 根据 第 5 条 授权 策略 ， 注 册 用 户 具有 比 第 四 条 授 
权 高 一 个 等 级 的 权限 ， 即 注册 用 户 除了 具有 读 取 版 本 库 权 限 外 ， 还 可 以 
向 版 本 库 的 refs/for/ 引用 推送 ， 产 生 评 审 任务 的 权限 。 


之 所 以 这 种 可 写 的 权限 也 放 在 “Read Access” 类 别 中 ， 是 因为 Git 的 





写 操作 必须 建立 在 拥有 读 权 限 之 上 ， 因 此 Gerrit 将 其 与 读 取 都 放 在 “Read 





Access” 归 类 之 下 ， 


只 不 过 高 一 个 级 别 。 


对 于 注册 用 户 : 根据 第 2 条 授权 策略 ， 在 向 服务 器 推送 提交 的 时 
候 ， 忽 略 对 提交 中 Authot 字 段 的 邮件 地 址 检查 。 这 个 在 之 前 已 经 讨论 


对 于 注册 用 户 : 根据 第 1 条 授权 策略 ， 注 册 用 户 具有 代码 审核 的 


一 般 权 限 ， 即 能 够 将 评审 任务 设置 为 “+1” 级 别 (看 起 来 不 错 ， 但 需要 
通过 他 人 认可 ) ,或 者 将 评审 任务 标记 为 “-1” (评审 任务 没有 通过 不 


能 提交 ) 。 
. 对 于 管理 员 : 根据 第 3 条 策略 ， 管 理 员 能 够 读 取 任意 版 本 库 。 


上 面 的 授权 策略 仅仅 对 评审 流程 进行 了 部 分 设置 。 如 : 提交 能 够 进 
入 评审 流程 ， 因 为 登录 用 户 《〈 注 册 用 户 ) 可 以 将 提交 以 评审 任务 的 方式 
上 传 ， 注册 用 户 可 以 将 评审 任务 标记 为 “+1: 看 起 来 不 错 ， 但 需 其 他 人 
认可 ”但 是 没有 人 有 权限 可 以 将 评审 任务 提交 逐一 合并 到 正式 的 版 本 
库 中 ， 即 没 人 能 够 对 评审 任务 做 最 终 的 确认 及 提交 ， 因 此 评审 流程 是 不 


完整 的 。 














有 两 种 方法 可 以 实现 对 评审 最 终 确认 的 授权 ， 一 种 是 赋予 特定 用 户 
Verified 类 别 中 的 “+1:Verified” 的 授权 ， 男 外 一 个 方法 是 赋予 特定 用 户 
Code Review 类 别 中 更 高 级 别 的 授权 : “+2:Looks good to me， 
approved”。 要 想 实 现 对 经 过 确认 的 评审 任务 的 提交 ， 还 需要 赋予 特定 用 
户 Submit 类 别 中 的 “+1:Submit" 授 权 。 





下 面 的 示例 中 ， 创 建 两 个 新 的 用 户 组 Reviewer 和 Verifier， 并 为 其 赋 
予 相应 的 授权 。 


可 以 通过 Web 界 面 或 命令 行 创 建 用 户 组 。 如 果 通 过 Web 界 面 添加 用 
户 组 ， 选 择 “Admin” 菜 单 下 的 “Groups” 子 菜单 ， 如 图 32-15。 


Al | My | Admin | Documentation 
Groups Projects Change #, SHA-1, tr:iid, 


Jiang Xin <jiangxin@moon.ossxp.com> | Settings | Sign Out 
owner:email or review Search | 
Groups 


Group Name Description 
b Administrators Gerrit Site Administrators 
Anonymous Lsers Any user, signed-in or not 
Non-Interactive Users Users who perform batch actions on Gerrit 
Reyistered Users Any signed-in user 


Create New Group 


[Reviewer 


Create Group | 





图 32-15 ” Gerrit 用 户 组 创建 


输入 用 户 组 名 称 后 ， 点 击 “Create Group” 按 钮 ， 进 入 创建 用 户 组 后 
的 设置 页 ， 如 图 32-16。 


Al | My | Admin | Documentation Jiang Xin <jiangxin@moon.ossxp.com> | Settings | Sign Out 
Groups Projects hange #, SHA-1 tr:id, ownernemall or reviewer.ema Search 


Group Reviewer 
[Reviewer 


FE UF 
Owners 
[Reviewer 
Description 


县 有 设置 审核 通过 的 权限 


Save Description 


Members 


ame Or Email 

Member Emall Address 
口 Jiang Xin liangxin@moon.ossxp.com 
Delete 





图 32-16 Gerrit 用 户 组 设置 页 


注意 到 在 用 户 设置 页 面 中 有 一 个 Owners 字 上 段 名 称 和 用 户 组 名 称 相 


同 ， 实 际 上 这 是 Gerrit 关 于 用 户 组 的 一 个 特别 的 功能 。 一 个 用 户 组 可 以 
设置 男 外 一 个 用 户 组 为 本 用 户 组 的 Owners， 属 于 Owners 用 户 组 的 用 户 
实际 上 相当 于 本 用 户 组 的 管理 者 ， 可 以 添加 用 户 、 修 改 用 户 组 名 称 等 。 
不 过 一 般 最 常用 的 设置 是 使 用 同名 的 用 户 组 作为 Owners。 





在 用 户 组 设置 页 面 的 最 下 面 ， 是 用 户 组 用 户 分 配对 话 框 ， 可 以 将 用 
户 分 配 到 用 户 组 中 。 


图 32-17 是 添加 了 两 个 新 用 户 组 后 的 用 户 组 列表 : 


M | My | Admin | Documentation | S Jiang Xin <jiangxin@moon.ossxp.com> | : 
Groups Prolects 


Groups 


Group Name 
pb Administraior 


nonymo 
Non-INteractive ser 


Reyistered Users Any signed-in user 
有 具有 设置 审核 通过 的 权限 
设置 评审 测试 通过 





图 32-17 Gerrit 用 户 组 列表 


接 下 来 要 为 新 的 用 户 组 授权 ， 需 要 访问 “Admin” 亲 单 下 
的 “Projects” 子 沫 单 ， 点 击 对 应 的 项 目 进入 权限 编辑 界面 。 为 了 简便 起 
见 ， 选 择 “--All Projects--”， 对 其 授权 的 更 改 可 以 被 其 他 的 所 有 项 目 共 
译 。 图 32-18 是 为 Reviewer 用 户 组 建立 授权 过 程 的 页 面 。 


Al | My | admin | Documentation 
Groups Projects 


Project -- All Projects -- 

General | Access Rights 

Access Category Group Name 
口 code Review Registered Users 
口 Forge ldentity Registered Users 
口 Read Access Administrators 
口 Read Access Anonymous Users 
口 Read Access Registered Users 
Delete 


Category: Code Review| 王 | 


Rerference Name 
refsiheads” 
refs 六 

refs” 

Te 个 产 

refs” 


Jiang Xin <jiangxi : Settings 


Femitted Range 
-1 1would prefer that you didn't submit this 
+1 Looks go0d to me, but someone else muUst approve 


+1 Forge Author Identity 
+1 Read actess 
+1 Read access 
+2 Upload permission 


Group Name: Reviewer 


Reference Name: | 
Permitted Range: -2: Do notsubmit v | 
到 


*2.Looks good to me, approved 


-2: Do not submit 


Add Access Rig 1: would prefer thatyou didnt submit this 


0:No score 


+1:Looks good to me, but someone else must approye 
*2: Looks good to me, approyed 


Report Bug 








图 32-18 ”为 Reviewer 用 户 组 建立 授权 


分 别 为 两 个 新 建立 的 用 户 组 分 配 授 权 ， 如 表 32-3 所 示 。 编 号 从 6 开 
台 ， 是 因为 这 里 补充 的 授权 是 建立 在 前 面 的 默认 授权 列表 的 基础 上 的 。 





表 32-3 新 用 户 组 权限 分 配 表 





编号 类 别 用 户 组 名 称 引用 名 称 权限 范围 
-2: Do not Submit 
+ 
6 Code Review Reviewer refs/ Lookygodd tome approwed 
-1: Fails 
2 a 
了 Verified Verifier refs/ +1: Verified 
8 Submit Verifier refs/* +1: Submit 


这 样 ， 就 为 Gerrit 所 有 的 项 目 设 定 了 可 用 的 评审 工作 流 。 


32.10 ”Gerrit 评 审 工作 流 实战 


分 别 再 注册 两 个 用 户 账号 dev1@moon.ossxp.com 和 
dev2@moon.ossxp.com， 两 个 用 户 分 别 属于 Reviewer 用 户 组 和 Verifier 用 
户 组 。 这 样 Gerrit 部 车 中 就 拥有 了 三 个 用 户 账号 ， 用 账号 jiangxin 进 行 代 
人 码 提交 ， 用 dev1 账 号 对 任务 进行 代码 审核 ， 用 dev2 账 号 对 审核 任务 进行 
最 终 的 确认 。 


32.10.1 开发 者 在 本 地 版 本 库 中 工作 


repo 是 Gerrit 的 最 佳 伴 但 ， 凡 是 需要 和 Gerrit 版 本 库 交 互 的 工作 都 封 
装 在 repo 命 令 中 。 关 于 repo 的 用 法 在 上 一 部 分 的 repo 多 版 本 库 协 同 的 章 
节 中 已 经 详细 介绍 了 。 这 里 只 介绍 开发 者 如 何 只 使 用 git 命 令 来 和 Gerrit 
服务 器 交互 。 这 样 也 可 以 更 深入 地 理解 repo 和 Gerrit 整 合 的 机 制 ， 具 体操 
作 过 程 如 下 。 


(1) 首先 克隆 Gerrit 管 理 的 版 本 库 ， 使 用 Gerrit 提 供 的 运行 于 29418 
端口 的 SSH 协 议 。 





$ git clone ssh://jiangxin@host:29418/hello.git 
Cloning into hello... 

remote: Counting objects: 3, done 

remote: Compressing objects: 100% (3/3) 
Receiving objects: 100% (3/3), done. 





(2) 然后 拷贝 Gerrit 服 务 器 提供 的 commit-msg 钓 子 脚本 。 





$ cd hello 
$ scp -P 29418 -p jiangxin@host:/hooks/commit-msg .git/hooks/ 





(3) 别 筷 了 修改 Git 配 置 中 提交 者 的 邮件 地 址 ， 以 便 和 Gerrit 中 注册 
的 地 址 保持 一 致 。 不 使 用 --global 参 数 调用 git config 可 以 只 对 本 版 本 库 的 
提交 设 定 提交 者 邮件 。 





$ git config user.email jiangxin@moon.ossxp.com 





(4) 然后 修改 readme.txt 文 件 并 提交 。 注 意 提交 的 时 候 使 用 了 “- 
s” 参 数 ， 日 的 是 在 提交 说 明 中 加 入 “(5〉 查看 一 下 提交 日 志 ， 会 看 到 其 
中 有 特殊 的 标签 。 





$ echo "gerrit review test" >> readme ,txt 
$ git commit -a -s -m "readme.txt hacked." 
[master c65ab49] readme ,txt hacked. 
1 files changed, 1 insertions(+), 0 deletions(-) 





(5) 查看 一 下 提交 日 志 ， 会 看 到 其 中 有 特殊 的 标签 。 





$ git 1og --pretty=full -1 

commit c65ab490f6d3dc36429b8f1363b6191357202f2e 

Author: Jiang Xin <jiangxin@moon.ossxp.com> 

Date: Mon Nov 15 17:50:08 2010 +0800 
readme ,txt hacked. 
Change-Id: Id7c9d88ebf5dac2d19a7e0896289de1lae6fb6a90 
Signed-off-by: Jiang Xin <jiangxin@moon.ossxp.com> 





提交 说 明 中 出 现 了 “Change-Id:” 标 签 ， 这 个 标签 是 由 钩子 脚 


本 “commit-msg” 目 动 生 成 的 。 至 于 这 个 标签 的 含义 ， 在 前 面 Gerrit 的 实 
现 原 理 中 已 经 介绍 过 。 


好 了 ， 准 备 把 这 个 提交 推送 到 服务 器 上 吧 。 


32.10.2 ”开发 者 癌 审 核 服务 器 提交 


由 Gerrit 控 制 的 Git 版 本 库 不 能 直接 提交 为 正确 设置 的 Gerrit 服 务 
器 ， 会 拒绝 用 户 直 接 回 refs/heads/#* 推 送 。 





$ git status 
# On branch master 
# Your branch is ahead of 'origin/master' by 1 commit. 
# 
nothing to commit (working directory clean) 
$ git push 
Counting objects: 5, done. 
Writing objects: 100% (3/3), 332 bytes, done. 
Total 3 (delta 0), reused 0 (delta 0) 
To ssh://jiangxin@host:29418/hello.git 
! [remote rejected] master -> master (prohibited by Gerrit) 
error: failed to push some refs to 'ssh://jiangxin@host:29418/hello.git' 





直接 推送 就 会 遇 到 “prohibited by Gerrit” 的 错误 。 


正确 的 做 法 是 向 特殊 的 引用 推送 ， 这 样 Gerrit 会 自动 将 新 提交 转换 
为 评审 任务 。 





$ git push origin HEAD:refs/for/master 
Counting objects: 5, done. 
Writing objects: 100% (3/3), 332 bytes, done. 
Total 3 (delta 0), reused 0 (delta 0) 
To ssh://jiangxin@host:29418/hello.git 

* [new branch] HEAD -> refs/for/master 


= 二 = 一 = 


看 到 了 吗 ， 向 refs/fovmaster 推 送 成 功 。 
32.10.3 ”审核 评审 任务 


以 Dev1l 用 户 登 录 Gerrit 网 站 ， 点 击 “Al” 菜 单 下 的 “Open” 标 签 ， 可 以 
看 到 新 提交 到 Gerrit 的 状态 为 Open 的 评审 任务 ， 如 图 32-19。 


Al | My | Admin | Documentation | 


Dev1<dev1@moon.ossxp.com> | Settings | Sigan Out 
Open Merged Abandoned status:open 


Search for status:open 








Search 


加 Subyect Project Branch Updated VV 只 
» Id7c9d88e readmebd hacked hello master 6:08 PM 








图 32-19 ”Getrit 评 审 任 务 列表 


点 击 该 评审 任务 ， 显 示 关 于 此 评审 任务 的 详细 信息 ， 如 图 32-20。 


=Changeid7c5d66erreadme'txehascked. iocaihost Code Review -Tewease 二 5G6 5 


文件 (E) ”编辑 (E) ”查看 [V) ”历史 (S) 书签 (B) ” 拆 分 (P) 工具 {I) ” 必 助 (H) 
二 vONRY BYv :https:/ocalhost/gerrit/#change,l 


Changeld7c9d88e: readmet... 园 (© 


Al | My | Admin | Documentation | Dev1<dev1@moon.ossxp.com> | Settings | Sion © A 
OQpen Merged Abandoned status:open Search | 
A 
~ 


Change ld7c9d88e' readme.txt hacked. 


让 1d7c9d88ebf5dac2d19a7e0896289de1aeelb6a50 辆 ] readme .txt hacked 


J 灿 ang Xin 


Nov 15, 2010 3:08 PM 
Nov 15, 2010 5:08 PM 
Review in Progress 


Permalnk 加 


es NeedVerifed *1 (Verified) 
es。 Need Code Review +2 (Looks good to me, approved) 


Name or Email Add Reviewer 


> Dependencies 
VW patch Set 1 ce5ab490Bd3dc36429b8f1363b619135720212e (gitweb) 


Author Jiang Xin <jangxin@moon.ossyp.com> Nov 15, 2010 5:50 PM 
CommRter Jiang Xin<pangxin@moon.ossyp.com> Nov 15, 2010 5:50 PM 


checkout | Dull | cherry-pick | patch Anonymous HTTP | SSH | HTTP 
Downioad 一 二 


Review Diff Al side-by-side | DiffAllUnified | 


File Path Comments DO 
» Commit Message Side-by-Side 
M readme bd +1,-0 Side-by-Side 
*1,-0 





< 


会 |I v 





图 32-20 ” Gerrit 评审 任务 概述 


hello Change-Id: Id7c9d88ebf5dac2d19a7e0896289delae6fb6a9( 
master Signed-off-by: Jiang Xin <jiangxin@moon .ossxp.com> 


git fetch https://1ocalhost/gerrit/p/hello refs/changes/01/1/1 && git checkout FETCH_HE 


A 
Unified 
Unified 


《> 


ET 
w javascript:void(0); 钱 条 FoxyProxy; 禁用 国王 门 品 从 | 计 | 现 在 :2 尼 全 | 仿 天 8 个 Se 





从 URL 地 址 栏 可 以 看 到 该 评审 任务 的 评审 编号 为 1。 目 前 该 评审 任 
务 有 一 个 补丁 集 (Patch Set 1) ， 可 以 点 击 “Diff All Side-by-Side” 查 看 变 
更 集 ， 以 决定 该 提交 是 否 应 该 被 接受 。 作 为 测试 ， 先 让 此 次 提交 通过 代 
引 审核 ， 于 是 以 Dev1 用 户 身 份 点 击 “Review” 投 钮 。 点 击 “Review” 按 钮 


后 ， 弹 出 代码 评审 对 话 框 ， 如 图 32-21。 











A | My | Admin | Documentation | Devi<devi@moon.ossxp.com> | Settings | Sign Out 
OQpen Merged Abandoned status:op en Search 


Change ld7c9d88e - Patch Set 1: Publish Comments 


hange-/ld. IdicSdasebf5dac2d1i9a7e 0 39delaedfbdagdd 司 





readme ,txt hacked. 
Owner Jiana Xin 


Diect hello Change-1d: Id7c9d88ebfs5daczdl9a7e0896289delae6fb5a90 
Branch master Signed-off-by: Jiang Xin <jiangxin@moon .ossxp.com> 
Topk 


Uploaded Nov15, 2010 6-08 PM 

Updsied Nov15. 2010 6:08PM 

Stotus Reviewin Proyress 
Permalink Wl 
Code Review: 

加 ,2 Looks good to me, approved 
Casiooks good to me, but someone else must approve 
CO 0No aoore 
OO "1 | would prefer that you didn't submit ths 
OO 2 00 notsubmit 


Cover Messaye: 


一 


Publish Comments Cancel 





图 32-21 ”Getrit 任 务 评审 对 话 框 


选择 “+2:Looks good to me，approved.”， 点 击 按钮 “Publish 
Comments” 以 通过 评审 。 注 意 因 为 没有 给 Dev1 用 户 (Reviewer 用 户 组 ) 
授予 Submit 权 限 ， 因 此 此 时 Dev1 还 不 能 将 此 审核 任务 提交 。 


Dev1 用 户 做 出 通过 评审 的 决定 后 ， 代 码 提交 者 jiangxin 会 收 到 一 封 
邮件 ， 如 图 32-22。 


ba v lg 下 入 垃 
发 件 人 Dev1 (Code Review) <gerrit@localhost> 团 四 和 | 回转 发 | 各 归档 @ 垃圾 | 全 删除 
村 站 [master] Change Id7c9d88e: (hello) readme.txt hacked. 


回复 至 devl@moon.ossxp.com 


18:27 


收 件 人 jiang Xin <jiangxin@moon.ossxp.com> 其 他 操作 





Comments on Patch Set 1: 
Patch Set 1: Looks good to me，approved 


To respond, visit https://localhost/gerrit/1 





图 32-22 ”Gerrit 通 知 邮 件 
32.10.4 评审 任务 没有 通过 测试 


下 面 以 Dev2 账 号 登录 Gerrit， 查 看 处 于 打开 状态 的 评审 任务 ， 如 图 
32-23。 会 看 到 评审 任务 1 的 代码 评审 已 经 通过 ， 但 是 尚未 进行 测试 检查 
(Verify) 。 于 是 Dev2 下 载 该 补丁 集 ， 在 本 机 进行 测试 。 





_ 则 | My | Admin | Documentation | Developer2 <dev2@moon.ossxp.com> | Settings | Sign Out 
QOpen Merged Abandoned status:open Search | 


Change Id7c9d88e.: readme.txt hacked. 


Change-ic ld7cs9d88ebf5dac2d19a7e0896289de1ae6lb6a90 而 


Owner Jiang xin 
Proiect hello Change-Id: Id7c9d88ebfSdac2d19a7e0896289delae6fb6a9I 
Branch master Signed-off-by: jiang Xin <jiangxin@moon .ossxp.com> 
Topkc 

Upioaded Nov15, 2010 6:08 PM 

Updsated Nov15, 2010 6:27 PM 
Status Review in Progress 


readme .txt hacked. 


Permalink 图 


Reviewer Veriied Coue Review 
Dev1 v Looks good to me, approved 


se NeedVerifed+1 (Verified) 
[Name or Emall Add Reviewer | 


b> Dependencies 
VW patch Set 1 cbs5ab490Bd3dc36429b8f1363b6191357202f2e (gitweb) 


Author Jiang Xin <jiangxin@moon.ossxp.com>» Nov 15, 2010 5:50 PM 
Commiter Jiang Xin dd ossxp.com>» Nov 15, 2010 5:50 PM 
Anonymous HTTP | SSH | HTTP 
git fetch tps //localhost/gerrit/p/hello refs/changes/01/1/1 && git checkout FETCH_HE 


Review Diff All Side-by-Side Diff All Unified | 





图 32-23 ”Gerrit 评 审 任 务 显 示 


假设 测试 没有 通过 ，Dev2 用 户 点 击 该 评审 任务 的 “Review” 按 钮 ， 重 
置 该 任务 的 评审 状态 ， 如 图 32-24。 


Al | My | Admin | Documentation Developer2 <dev2@moon.ossxp,com> | SettiNnds 
Open Merged Abandoned status:open Search 


Change ld7c9d88e - Patch Set 1: Publish Comments 


Change-id: id7c9d88ebf5dac2d19a7e0896289detae6rb6390 丑 


Owner Jiang Xin 
Project hello Change-Id: Id7c9d88ebf5dac2d1l9a7e0896289delae6fb6a9d 
Branch master Signed-off-by: Jiang Xin <jiangxin@moon .ossxp.com> 


readme .txt hacked. 


Topic 

Upjoaded Nov15,2010 6:08 PM 
Upaated Nov15 2010 627 PM 
Status Review in Proyress 
Permalink 区 

erified: 
O +*1 Verifiaed 
OO 0 No score 


© .1Faits 


ode Review: 
OO +1Looks good to me, but someone else must approve 
©® ONoscore 
O -1 1 would prefer that you didn't submit this 


Over Message: 


一 


Publish Comments Publish and Submit Cancel 





图 32-24 ”Gerrit 评 审 任务 未 通过 


注意 到 图 32-24 中 Dev2 用 户 的 评审 对 话 框 有 三 个 按钮 ， 多 出 
的 “Publish and Submit” 按 钮 是 因为 Dev2 拥 有 Submit 授 权 。Dev2 用 户 在 上 
面 的 对 话 框 中 选择 了 “-1:Fails”"， 点 击 “Publish Comments” 按 钮 ， 该 评审 
任务 的 评审 记录 被 重 置 ， 同 时 提交 者 和 其 他 评审 参与 者 会 收 到 通知 邮 
件 ， 如 图 32-25。 


牛人 Developer2 (Code Review) <gerrit@localhost> 
生灵 [master] Change Id7c9d88e: (hello) readme.txt hacked. 
1] 复 至 dev2@moon.0ssxp.com 
皮 件 人 Jiang Xin <jlangxin@moon.ossxp.com> 
沙 过 Devl <devl1@moon.ossxp.com> 其 他 操作 下 


Comments on Patch Set 1: 


Patch Set 1: Fails 


To respond, visit https://\localhost/gerrit/] 








图 32-25 ” ”Gerrit 通知 邮 件 : 评审 未 通过 


32.10.5 重新 提交 新 的 补丁 集 


提交 者 收 到 代码 被 打 回 的 邮件 ， 一 定 很 难过 。 不 过 这 恰恰 说 明了 这 
个 软件 过 程 已 经 相当 的 完善 ， 现 在 发 现 问题 总 比 在 集成 测试 时 甚至 被 客 
户 发 现 要 好 得 多 吧 。 





根据 评审 者 和 检验 者 的 提示 ， 开 发 者 对 代码 进行 重新 修改 。 下 面 的 
Bugfix 过 程 仅 仅 是 一 个 简单 的 示例 ，Bugfix 没 有 这 么 简单 的 ， 对 
9 5 





$ echo "fixed" >> readme.txt 





重新 修改 后 ， 需 要 使 用 --amend 参 数 进行 提交 ， 即 使 用 前 次 提交 的 
日 志 重 新 提交 ， 这 一 点 非常 重要 。 因 为 这 样 就 会 对 原 提交 说 明 中 
的 “Change-Id:” 标 签 予 以 原样 保留 ， 当 再 将 新 提交 推送 到 服务 器 时 ， 
Gerrit 不 会 为 新 提交 生成 新 的 评审 任务 编号 ， 而 是 重用 原 有 的 任务 编 
号 ， 将 新 提交 转化 为 老 评 审 任务 的 新 补丁 集 ， 有 具体 操作 过 程 如 下 。 





(1) 在 执行 git commit--amend 时 ， 可 以 修改 提交 说 明 ， 但 是 注意 不 


要 删除 Change-Id 标 签 ， 更 不 能 修改 它 。 





$ git add -u 

$ git commit --amend 

readme ,txt hacked with bugfix. 

Change-Id: Id7c9d88ebf5dac2d19a7e0896289de1lae6fb6a90 
Signed-off-by: Jiang Xin <jiangxin@moon.ossxp.com> 


# Please enter the commit message for your changes，Lines starting 
# with '#' will be ignored, and an empty message aborts the commit 
# On branch master 

# Your branch is ahead of 'origin/master' by 1 commit. 

## 

# Changes to be committed : 

# (use "git reset HEAD^1 <file>..." to unstage) 

# 

# modified: readme .txt 

# 





(2) 提交 成 功 后 ， 执 行 git ls-remote 命 令 会 看 到 Gerrit 维 护 的 Git 库 
中 只 有 一 个 评审 任务 (编号 1) ， 且 该 评审 任务 只 有 一 个 补丁 集 (Patch 
Set 1) 。 





$ git ls-remote origin 


82c8fc3805d57ccod17d58e1452e21428910fd2d HEAD 
c65ab490f6d3dc36429b8f1363b6191357202f2e refs/changes/01/1/1 
82c8fc3805d57ccod17d58e1452e21428910fd2d refs/heads/master 


| 


(3) 把 修改 后 的 提交 推送 到 Gerrit 管 理 下 的 Git 版 本 库 中 。 注 意 依旧 
推送 到 refs/for/master 引 用 中 。 





$ git push origin HEAD:refs/for/master 
Counting objects: 5, done. 
Writing objects: 100% (3/3), 353 bytes, done. 
Total 3 (delta 0), reused 0 (delta 0) 
To ssh://jiangxin@host:29418/hello.git 

* [new branch] HEAD -> refs/for/master 





(4) 推送 成 功 后 ， 再 执行 git ls-remote 命 令 ， 会 看 到 唯一 的 评审 任 
务 ( 编 号 1) 有 了 两 个 补丁 集 。 





$ git ls-remote origin 


82c8fc3805d57ccod17d58e1452e21428910fd2d HEAD 
c65ab490f6d3dc36429b8f1363b6191357202f2e refs/changes/01/1/1 
1df9e8e05fcf97a46588488918a476abd1df8121 refs/changes/01/1/2 
82c8fc3805d57ccod17d58e1452e21428910fd2d refs/heads/master 





32.10.6 ”新 修订 集 通 过 评审 


当 提 交 者 重新 针对 评审 任务 进行 提交 时 ， 原 评审 任务 的 审核 者 会 收 
到 通知 邮件 ， 提 醒 有 新 的 补丁 集 等 竺 评审， 如 图 32-26。 


发 件 人 jiang Xin (Code Review) <gerrit@localhost> 二 
行 旭 [master] Change Id7c9d88e: (hello) readme.txt hacked. 
回复 至 jiangxin@moon.ossxp.com 
收 件 人 Developer2 <dev2@moon.ossxp.com> ,Devl <devl@moon.ossxp.com>D 


Hello Developer2, Dev], 


I'd like you to reexamine change Id7c9d88e. 
Change Id7c9d88e (patch set 2) for master in hello: 


readme. txt hacked with bugfix. 


Change-Id: Id7c9d88ebf5dac2d19a7e0896289delae6fb6a99 


Signed-off-by: Jiang Xin <jiangxinfmnoon .ossxp.com> 


M readme. txt 
1 file changed, 2 insertions(+), © deletions(-) 


git pull ssh://localhost:29418/hello refs/changes/91/1/2 





Gerrit-Revliewer 


Gerrit-Reviewe 








图 32-26 ” Gerrit 通知 邮 件 : 新 补丁 集 


登录 Gerrit 的 Web 界 面 ， 可 以 看 到 评审 任务 1 有 了 新 的 补丁 集 ， 如 图 
32-27 所 示 。 


Reviewer Verijled Code Review 
Jiang Xin 
Developar? 区 
Daev1 
a Need Verified +1 tverfied) 
sa Need Code Review +2 (Looks 900d to me, approved) 


Add Reviewer | 


bP Dependencies 
Pb Patch Set 1 cosabdl90pBdSdc36429b8f1363b65151357202f2e (yitwab) 
WV patch Set 2 1dBeBeQsfc7 a465884688918a476abd1d9121 (gitweb) 


Author Jiana xXin <jiangin@moon.ossxp com> Mov 15, 2010 5.50 PM 
Commiter Jiang Xin <jiangdn@@moon.0ssxp com> Nov 15, 2010 7:03 PM 
checkowut | pull | sherry-pick | patch nonymeouse HTTP | SSH | HTTP 
Downtoad git fetch ssh://dev2@localhost:29418/hello refs/changes/01/1/2 && git checkout FETCH_HE 


Review Diff All Side-by-Side Diff All Unified | 





Fe Path Comments Om 
上 ComimitMe55age Sideby5ide 


M readmetd Side-by-Side 





图 32-27 ”Gerrit 新 补丁 集 显 示 


再 经 过 代码 审核 和 测试 ， 这 次 Dev2 用 户 决 定 让 评审 通过 ， 点 击 
了 “Publish and Submit” 按 钮 。Submit (提交 ) 动作 会 将 评审 任务 
(refs/changes/01/1/2) 合并 到 对 应 分 文 “master) 中 。 图 32-28 显 示 的 是 
通过 评审 完成 合并 的 评审 任务 1。 


Al | My | Admin | Documentation Developer2 <dava 
Changes Drafts Watched Changes =tanrnd Changes 


Change ld7c9d88e: readme .txt hacked With os 


Changetd: Id7c9d88eb15dac2d19a7e0696289de1aebb6300 剧 
Owner Jiang Xin 
Project hello Cange-id: ldrcodiBiebt dacidif Tel Ee acl fut 
Brench master 4 $m RIN i ND, PON 
Topic 
Upioaded Nov 15. 2010 6:08 PM 
Upostied Nov15, 2010 7:14 PM 
S153 Merdged 


rea, tHe Nached WIth budgtin, 


Penman 瑟 


Reviewer Verified Coce Feview 
JanaXin 
Davi W LOOKS EEA MD,» 


Developer2 Vv Wenifie 


FP Included in 


pb Dependencies 
BP patchSet1 cB5abaanBdu3dc3d2Nb1Snsr Pe [ob 
VPpatchset2 1deeBe05rc7a465834089164476shd1dBI2l [oto 





图 32-28 ” ”Gerrit 合并 后 的 评审 任务 


32.10.7 ”从 远程 版 本 库 更 新 


当 Dev1 和 Dev2 用 户 完成 代码 评审 后 ， 提 交 者 会 收 到 多 封 通知 邮 
件 。 这 其 中 最 让 人 激动 的 就 是 代码 被 接受 并 合并 到 开发 主线 (master) 
中 ， 如 图 32-29 所 示 ， 这 令 开 发 者 感到 多 么 荣 沭 啊 。 


\ Developer2 (Code Review) <gerrit@localhost> 
[master] Change Id7c9d88e: (hello) readme.txt hacked with bugfix. 


至 dev2@moon.o0ssxp.com 
jang Xin <jiangxin@moon.ossxp.com> 
bi Devl <devl@moon.ossxp.com> 其 他 摊 作 Y 
Change Id7c9d88e by Jiang Xin submitted to master: 


readme.txt hacked with bugfix， 


Change-Id: Id7c9d88ebf5dac2d19a7e8896289delae6fb6a90 
Signed-off-by: Jiang Xin <jiangxin@noon.ossxp.com> 


M readme .txt 
1 file changed, 2 insertions(+), © deletions(-) 


Approvals: 
Developer2: Verified 
Devl: Looks good to me, approved 





图 32-29 ”Gettit 通 知 邮件 : 修订 已 合并 


代码 提交 者 执行 git pul， 和 Gerrit 管 理 的 版 本 库 同 步 。 





$ git ls-remote origin 


1df9e8e05fcf97a46588488918a476abd1df8121 HEAD 
c65ab490f6d3dc36429b8f1363b6191357202f2e refs/changes/01/1/1 
1df9e8e05fcf97a46588488918a476abd1df8121 refs/changes/01/1/2 
1df9e8e05fcf97a46588488918a476abd1df8121 refs/heads/master 
$ git pull 
From ssh://jiangxin@host:29418/hello 

82c8fc3..1df9e8e master -> origin/master 


Already up-to-date. 


丘 === 二 二 = 一 = 


32.11 更 多 Gerrit 参 考 


Gerrit 涉 及 的 内 容 非 党 庞杂， 还 有 诸如 和 Gitweb、git-daemon 整 合 ， 
Gerrit 界 面 定制 等 功能 ， 恕 不 在 此 一 一 列举 。 可 以 直接 参考 Gerrit 网 站 上 
的 帮助 是。 


[1] http:/ /gettit.googlecode.com/svn/documentation/ 


第 33 章 ”Git 版 本 库 托管 


想 不 想 在 互联 网 上 为 自己 的 Git 版 本 库 建 立 一 个 克隆 ? 这 样 就 再 也 
不 必 为 数据 的 安全 担忧 (异地 备份 )， 还 可 以 和 他 人 共享 数据 、 协 同 工 
作 ? 但 是 这 样 做 会 不 会 很 贯 呢 ? 比如 要 购买 域名 、 虚 拟 主机 、 搭 建 Git 
服务 器 什么 的 ? 


实际 上 可 以 免费 获得 这 种 服务 (Git 版 本 库 托 管 服务 )! GitHub、 
Gitorious 等 都 可 以 免费 提供 这 些 服务 。 


33.1 Github 





如 果 您 是 按部就班 式 地 阅读 本 书 ， 那 么 可 能 早 就 注意 到 本 书 的 很 多 
示例 版 本 库 都 是 放 在 GitHub 上 的 。GitHub 提 供 了 Git 版 本 库 托管 服务 ， 
既 包括 收费 的 商业 支持 ， 也 提供 免费 的 服务 ， 很 多 开源 项 目 把 版 本 库 直 
接 放 在 了 GitHub 上 ， 如 : jQuery、curl、Ruby on Rails 等 。 





注册 一 个 GitHub 账 号 非常 简单 ， 访 问 GitHub 网 
站 : https://github.com/ ， 点 击 羔 单 中 的 “Pricing and Signup” 就 可 以 看 到 
GitHub 的 服务 列表 (如 图 33-1) 。 会 看 到 其 中 有 一 个 免费 的 服务 : “Free 
for open source”， 并 且 版 本 库 托 管 的 数量 不 受 限 制 。 当 然 免费 的 午餐 是 
不 管 饱 的 ， 托 管 的 空间 只 有 300MB， 而 且 不 能 创建 私有 版 本 库 。 





github 


Plans & Pricing 
oin today and collaborate with the smartes evelopers In the wo 


30 Free for open source 
Unlimited public repositories and unlimited public collaborators 


Creaie a free accoun1 


Micro $7imo Small mo Medium $22mo 
5Private Repositories 10 Private Repositories 20 Private Repositories 
1 Private Collaborator 5 Private Collaborators 10 Private Collaborators 

Unlimited public repositories Unlimited public repositories Unlimited public repositories 


Unlimited public collaborators Unlimited public collaborators Unlimited public collaborators 





图 33-1  GitHub 服 务 价 目 表 


点 击 按钮 “Create a free account”， 就 可 以 创建 一 个 免费 的 账号 。 
GitHub 的 用 法 和 前 面 介绍 的 Gerrit Web 界 面 的 用 法 很 类 似 ， 一 旦 账号 创 
建 ， 应 该 马上 为 新 建立 的 账号 设置 公 钥 ， 以 便 能 够 用 SSH 协 议 读 写 自己 
账号 下 创建 的 版 本 库 ， 如 图 33-2 所 示 。 


账户 设置 公开 档案 ， 
账户 设置 查看 你 的 公开 档案 


账户 总 览 ”通知 中 心 
至 少 需要 一 条 SSH 公 钥 ,你 才能 推送 git 仓库 到 GitHub。 
Free 0/0 0/0 0.00GB/0.30GB 
和 下 ee 。 em 


至 少 需要 一 条 SSH 公 钥 ， 你 才能 推送 git 仓库 到 GitHub。 


SSH 公 钥 


ssh-rsa Nine fr 本 | 
ni TEC BR/ qu GoUPDv2yYINYIE /iNABU? cG11 
el XHn5CK i DCz pi + 
ZrIWIDr 3DCaicRiaxoGliyScNOPAGnA+3r2GI 
C7 nj2ZzlUyPEmSBAnTZHFONt i Sbh63Pcyw8cdzb 问 
Dor ee cpyip7 hnFOGDpF+ang 
CEX9S s1Bhy rdOlefyl28t6I nbao)EeFn?2STO+FE dsdeG sftydA3tvi ss 





滔 加 公 钥 ”or 到 消 


图 33-2”GitHub 上 配置 公民 


创建 仓库 的 操作 非常 简单 ， 首 先 点 击 菜单 上 的 “ 主 
页 ”(Dashboard) ， 再 点 击 右 侧 边栏 上 的 “新 建仓 库 ? 按 钮 就 可 以 创建 新 
的 版 本 库 了 ， 如 图 33-3 所 示 。 


ith b 总 liangxin 让 箱 HH 雪 讲 
github en 
龟 你 好 , jangxn Wic add --interactive ! ， 图 qimi7 四 条 
新 闻 订阅 源 “你 的 动作 ”请 求 抓 取 全 六 多 二 
gif 欢迎 来 到 SItHu5 ! 毛 下 来 该 做 件 必 ? 
me 你 的 仓库 EE3 


所 有 项 目 企 亩 








图 33-3” GitHub 页 面 上 的 新 建 版 本 库 按钮 


新 建 版 本 库 会 浪费 本 来 就 不 多 的 托管 空间 ， 从 GitHub 上 已 有 的 版 本 
库 派 生 〈fork) 一 个 克隆 是 一 个 好 办 法 。 首 先 通 过 GitHub 搜 索 版 本 库 名 
称 ， 找 到 后 点 击 “ 派 生 ” 按 钮 ， 就 可 以 在 自己 的 托管 空间 内 建立 相应 版 本 
库 的 克隆 ， 如 图 33-4 所 示 。 








图 33-4 ” 自 GitHub 上 的 版 本 库 派生 


版 本 库 建 立 后 就 可 以 用 Git 命 令 访 问 GitHub 上 托管 的 版 本 库 了 。 
GitHub 提 供 三 种 协议 可 供 访问 ， 如 图 33-5 所 示 。 其 中 SSH 协 议和 HTTP 协 


议 文 持 读 写 ，Gitrdaemon 提 供 只 读 访 问 。 对 于 自己 的 版 本 库 当 然 选择 文 
持 读 写 的 服务 方式 了 ， 其 中 SSH 协 议 是 首选 。 





三 jiangxin 主页 收 件 多 


github 


bi osha se 大 管理 员 ， 忆 取 消 关 注 ”4 派生。 证 请 求 拆 到 | 人 





图 33-5 ”版 本 库 访问 URL 





GitHub 的 流行 一 方面 是 因为 其 简便 的 Git 版 本 库 创建 和 托管 流程 ， 
男 一 方面 还 在 于 其 提供 了 实用 的 协同 工具 (如 在 线 Fork+Pull 
Request) ， 极 大 地 方便 了 团队 协同 和 项 目 管理 。GitHub 的 丰富 功能 
以 单独 再 写 一 本 书 ， 帮 我 来 完善 它 吧 。 网 
址 : http://gotgit.github.com/gotgithub/ 。 


33.2 Gitorious 


Gitorious 是 另外 一 个 Git 版 本 库 托 管 提 供 商 ， 网 址 
为 http://gitorious.org/ ， 如 图 33-6 所 示 。 最 酪 的 是 Gitorious 本 里 的 架 站 软 
件 也 是 开源 的 ， 可 以 通过 Gitorious 上 的 Gitorious 项 目 访 问 。 如 果 你 熟悉 
Ruby on Rails， 可 以 架设 一 个 本 地 的 Gitorious 服 务 。 





百 3itorious - GItoriou: 
文件 (E) ” 编 圈 (E) ”查看 (V] ”历史 (S) 书签 @)】” 拆 分 人 p)】 工具 (I) 才 助 {H] 
审 晴 ~v 多 佑 归 大曲 ~ | 国 http://gitorious org/gitorious 





giverievs - Giterisus | < 


-ee 


[| iiorious Q 





Gitorious 


呈 Open wiki 


Project information 
Labels: nd 


Ss 二 License 
Cione 二 Push wls ‘®) GIT WwW HTTP 


9IPWgnorious.OrgigMorlousimainline git Ownaer 
Creatled: O08 Ja o1 
Commli log Sr Source tree s Merge requesis (J G Clone reposiiory Waich Websile al 
Mallinglist a4 
六 完 威 欠 FoxyProxy: 党 月 国 习 门 本 必 | 注 | 现 在 6*C | 今天 :3125 








图 33-6 ”Gitorious 上 的 Gitorious 项 目 


第 6 篇 ”迁移 到 Git 


随 看 Git 版 本 控制 系统 的 成 熟 ， 越 来 越 多 的 项 目 把 版 本 控制 系统 迁 
移 到 了 Git 上 。 迁 移 大 多 是 无 损 的 ， 即 迁移 到 Git 后 完美 地 保留 了 之 前 的 
变更 历史 、 分 支 和 里 程 碑 。 如 果 你 正 打算 迁移 版 本 控制 系统 ， 本 篇 介绍 
的 版 本 库 迁 移 方法 和 注意 事项 将 会 为 你 提供 帮助 。 


本 篇 首先 会 介绍 CVS、Subversion、Mercurial 等 几 个 著名 的 开源 版 
本 控制 系统 如 何 迁 移 到 Git 上 。 除 这 些 之 外 的 其 他 版 本 控制 系统 也 许可 
以 找到 类 似 的 迁移 方案 ， 或 者 可 以 针对 git-fast-import 通 过 编程 的 方式 定 
制 转换 过 程 。 在 本 篇 的 最 后 ， 还 会 介绍 一 个 让 Git 版 本 库 改头换面 的 更 
为 强大 的 工具 git-filter-branch。 


第 34 章 ”CVS 版 本 库 到 Git 的 迁移 


CVS 是 最 早 被 广泛 使 用 的 版 本 控制 系统 ， 因 为 其 服务 器 端的 存储 结 
构 非常 简单 ， 至 今 仍 受到 不 少 粉 丝 的 钟爱 。 但 是 ， 它 毕竟 是 几 十 年 前 的 
产物 ， 因 为 设计 上 的 原因 ， 导 致 其 缺乏 现代 版 本 控制 系统 的 一 些 必 备 的 
功能 ， 如 : 没有 原子 提交 、 分 支管 理 不 便 〈 慢 ) 、 分 支 合 并 困难 (因为 
合并 过 程 缺 乏 跟 踪 ) 、 不 支持 文件 名 /目录 名 的 修改 ， 等 等 。CVS 的 很 
多 用 户 都 已 经 迁移 到 Subversion 这 一 更 好 的 集中 式 版 本 控制 系统 了 。 如 
果 你 还 在 使 用 CVS， 那 么 可 以 考虑 直接 迁移 到 Git。 





从 CVS 迁 移 到 Git 可 以 使 用 cvs2svn 软 件 包 中 的 cvs2git 命 令 。 为 什么 
该 项 目的 名 称 是 cvs2svn 而 非 cvs2git 呢 ?这 是 因为 该 项 目 最 早 是 为 CVS 版 
本 库 迁 移 到 Subversion 版 本 库 服务 的 ， 只 是 最 近 才 增加 了 CVS 版 本 库 转 
换 为 Git 版 本 库 的 功能 。cvs2svn 将 CVS 转 换 为 Subversion 版 本 库 的 过 程 一 
直 以 稳定 著称 ， 从 cvs2svn 2.1 版 开始 ， 增 加 了 将 CVS 版 本 库 转 换 为 Git 版 
本 库 的 功能 ， 这 无 疑 让 这 个 工具 更 具 生 命 力 ， 也 减少 了 之 前 CVS 到 Git 
库 的 转换 环节 。 在 推出 cvs2git 功 能 之 前 ，CVS 迁 移 到 Git 的 路 径 通常 是 : 
先 用 cvs2svn 将 CVS 版 本 库 迁 移 到 Subversion 版 本 库 ， 然 后 再 用 git-svn 将 
Subversion 版 本 库 迁 移 到 Git。 





关于 cvs2svn 及 cvs2git 的 更 多 信息 ， 可 以 参考 下 面 的 链接 : 


' http://cvs2svn.tigtis.org/cvs2svn.html 


* http:/ /cvs2svh.tigtis.ofg/cvs2pgithtml 


34.1 ”安装 cvs2svn 〈 含 cvs2git ) 
34.1.1 Linux 下 cvs2svn 的 安装 


大 部 分 Linux 发 行 版 都 提供 cvs2svn 1 的 发 布 包 ， 可 以 直接 用 平台 自 
带 的 cvs2svn 软 件 包 。cvs2svn 从 2.1 版 本 开始 引入 了 到 Git 库 的 转换 ，2.3.0 
版 本 有 了 独立 的 cvs2git 转 换 脚 本 ，cvs2git 正 在 逐渐 完善 当中 ， 因 此 请 尽 
量 选择 最 新 版 本 的 cvs2svn。 


例如 在 Debian 或 Ubuntu 下 ， 可 以 通过 下 面 的 命令 查看 源 里 面 的 
cvs2svn 版 本 。 


$ aptitude versions cvs2svn 
p 2.1.1-1 stable 990 
p 2.3.0-2 testing, unstable 1001 


可 以 看 出 Debian 的 Testing 和 Sid 仓 库 中 才 有 2.3.0 版 本 的 cvs2svn。 于 
是 执行 下 面 的 命令 安装 在 Testing 版 本 才 有 的 2.3.0-2 版 本 的 cvs2svn: 


$ sudo aptitude install cvs2svn/testing 








如 果 对 应 的 Linux 发 行 版 没有 对 应 的 版 本 也 可 以 从 源码 开始 安装 。 
cvs2svn 的 官方 版 本 库 在 http://cvs2svn.tigris.org/svn/cvs2svn/trunk 上 ， 已 
经 有 人 将 cvs2svn 项 目 转 换 为 Git 库 。 可 以 从 Git 库 下 载 源 码 并 安装 


cvVs2svn， 上 有 具体 操作 步骤 如 下 : 


(1) 下 载 cvs2svn 源 代码 。 





$ git clone git://repo.or.cz/cvs2svn.git 





(2) 进入 cvs2svn 源 码 目录 ， 安 装 cvs2svn。 





$ cd cvs2svn 
$ sudo make install 





(3) 安装 用 户 手 册 。 





$ sudo make man 





cvs2svn 对 其 他 软件 包 的 依赖 如 下 : 

. Python 2.4 或 以 上 版 本 ， 但 是 Python 3.x 暂 不 支持 。 

. RCS: 如 果 在 转换 中 使 用 了 --use-rcs， 就 需要 安装 RCS 软 件 包 口 。 
. CVS: 如 果 在 转换 中 使 用 了 --use-cvs， 就 需要 安装 CVS 软 件 包 D。 
Git: 1.5.4.4 或 以 上 的 版 本 。 之 前 版 本 的 Git 的 git fast-import 命 令 有 


Bug， 加 载 cvs29git 导 出 文件 有 问题 。 


34.1.2 ”Mac OS X 下 cvs2svn 的 安装 


Mac OS 义 下 可 以 使 用 brew 安 装 cvs2svn， 具 体 步 又 如 下 : 


(1) Mac OS X 默 认 安 装 的 Python 缺少 cvs2svn 依 赖 的 gdbm 模 组 ， 先 
用 brew 来 重新 安装 Python。 





$ brew install python 





(2) 安装 cvs2svn。 





$ export PATH=/usr/local/bin:$PATH 
$ brew install cvs2svn 





[1] http://cvs2svn.tigtis.org/ 
[2] http:/ /www.cs.purdue.edu/ homes/trinkle/ RCS/ 


[3] http://www.nongnu.org/ cvs/ 


34.2 版 本 库 转换 的 准备 工作 


34.2.1 有 版 本 库 转 换 注意 事项 


转换 CVS 版 本 库 时 应 该 注意 以 下 事项 : 


. 使 用 cvs2git 转 换 CVS 版 本 库 必 须 在 CVS 的 服务 器 端 执 行 ， 即 cvs2git 
必须 能 够 通过 文件 系统 直接 访问 CVS 版 本 库 中 的 “，v 文件 。 


. 在 转换 前 ， 确 保 所 有 人 的 修改 都 已 经 提交 到 CVS 版 本 库 中 。 


“ 在 转换 前 ， 停 止 对 CVS 版 本 库 的 访问 ， 以 免 在 转换 过 程 中 有 新 提 


交 写 入 。 


在 转换 前 ， 对 原始 版 本 库 进 行 备份 ， 以 免 误 操作 对 版 本 库 造 成 永 
久 的 破坏 。 


. 在 转换 完成 后 ， 永 久 停 止 CVS 版 本 库 的 写 入 服务 ， 可 以 仅 开 放 只 


这 是 由 于 cvs2git 是 一 次 性 操作 ， 不 能 对 CVS 的 后 续 提 交 执 行 增 量 式 
的 到 Git 库 的 转换 ， 因 此 当 CVS 版 本 库 转 换 完 毕 后 ， 须 停止 CVS 服 务 。 


` 先 做 小 规模 的 试验 性 转换 。 


转换 CVS 版 本 库 切 忌 一 上 来 就 对 整个 版 本 库 进行 转换 ， 等 到 友 现 日 
志 乱 码 、 文 件 名 乱码 、 提 交 者 ID 不 完全 后 重新 转换 会 浪费 大 量 的 时 间 。 











应 该 先 选 择 CVS 版 本 库 中 的 部 分 文件 和 目录 作为 样本 ， 进 行 小 规模 
的 转换 测试 。 


` 不 要 对 包含 CVSROOT 目 录 的 版 本 库 的 根 进行 操作 ， 可 以 先 对 服 
务 器 目录 的 布局 进行 调整 。 如 果 转 换 直 接 针 对 包含 CVSROOT 目 录 的 版 
本 库 根 目录 进行 操作 ， 会 导致 CVSROOT 目 录 下 的 文件 及 更 改 历史 也 被 
纳入 到 Git 版 本 库 中 ， 这 是 不 需要 的 。 


34.2.2 ”文件 名 乱码 问题 


CVS 中 保存 的 数据 在 服务 器 端 直接 和 同名 文件 (文件 多 了 一 个 “， 
ww 后缀) 相对 应 ， 如 果 转 换 的 CVS 版 本 库 是 从 其 他 平台 (如 Windows) 
上 拷贝 过 来 的 ， 就 可 能 因为 平台 本 身 字 符 集 不 一 致 而 导致 中 文 文件 名 包 
含 乱码 ， 从 而 在 CVS 版 本 库 的 转换 过 程 造成 乱码 。 可 以 先 对 有 问题 的 目 
录 名 和 文件 名 进行 重 命名 ， 将 其 转换 为 当前 平台 正确 的 编码 。 








34.2.3 ”提交 说 明 乱 码 问 题 





CVS 的 提交 说 明 中 如 果 使 用 了 中 文 ， 在 转换 后 的 版 本 库 中 可 能 显示 
为 乱码 ， 这 是 因为 CVS 的 提交 说 明 没 有 使 用 UTF-8 字 符 集 。 前 面 提 到 


过 ， 最 好 先进 行 小 规模 的 试验 性 转换 ， 然 后 再 对 整个 版 本 库 进行 正式 的 
转换 ， 束 是 为 了 防止 在 匆忙 转换 后 太 现 提交 说 明 中 出 现 乱 码 。 





下 面 来 看 一 个 使 用 了 中 文 提 交 说 明 的 CVS 版 本 库 。 版 本 库 是 按 如 下 
方式 部 署 的 : CVSROOT 为 /cvshome/user， 需 要 将 之 下 的 
jiangxin/homepage/worldhello 转 换 为 一 个 Git 版 本 库 。 先 检查 一 下 版 本 库 
中 的 数据 ， 找 出 典型 的 目录 用 于 转换 。 





典型 的 数据 是 这 样 的 : 包含 中 文 文件 名 ， 并 且 日 志 中 包含 中 文 。 例 
如 在 版 本 库 中 ， 执 行 CVS 碍 看 日 志 命令 ， 可 以 看 到 类 似 下 面 的 输出 。 





RCS file: /cvshome/user/jiangxin/homepage/worldhello/archive/2003/ .mhonarc ,db，V 
Working file: archive/2003/.mhonarc.db 

head: 1.16 

branch: 

Jocks: strict 

access list: 

symbolic names: 

keyword substitution: kv 

total revisions: 16; selected revisions: 16 

description: 

revision 1.16 

date: 2004-09-21 15:56:30 +0800; author: jiangxin; state: Exp; lines:+3 -3; commiti 
<DO><U+07B8><C4><D3>?<FE><B5><D8><A3><BB> 
<D0><U+07B8><C4><CB><D1><CB><F7><D2><FD><C7> 荣 





此 版 本 库 之 前 用 CVSNT 维 护 ， 默 认 字 符 集 为 GBK， 上 所 以 会 在 使 用 
UTF-8 字 符 集 的 操作 系统 上 看 到 乱码 。 那 么 这 里 选取 提交 说 明 存 在 乱码 
的 目录 进行 一 次 试验 性 的 转换 ， 具 体操 作 过 程 如 下 。 


(1) 调用 cvs2git 执 行 转换 ， 产 生 两 个 导出 文件 。 这 两 个 导出 文件 





将 作为 Git 版 本 库 创建 时 的 导入 文件 。 命 令 行 用 了 两 个 --encoding 参 数 设 
置 编码 ， 会 依次 尝试 将 日 志 中 的 非 ASCII 字 符 转 换 为 UTF-8 字 符 。 





$ cvs2git --blobfile git-blob.dat --dumpfile git-dump.dat \ 
--encoding utf8 --encoding gbk --username cvs2git \ 
/cvshome/user/jiangxin/homepage/worldhello/archive/2003/ 





(2) 成 功 导出 后 ， 产 生 两 个 导出 文件 ， 一 个 保存 各 个 文件 的 各 个 
不 同 版 本 的 数据 内 容 ， 即 在 命令 行 指定 的 输出 文件 git-blob.dat。 男 外 一 
个 文件 是 上 面 的 命令 行 指定 的 git-dump.dat， 用 于 保存 各 个 提交 的 相关 信 
息 〈 提 交 者 、 提 交 时 间 、 提 交 日 志 等 ) 。 可 以 看 出 保存 文件 内 容 的 导出 
文件 〈gitrblob.dat) 相对 更 大 一 些 。 





$ du -sh git*dat 
9.8M git-blob.dat 
24K git-dump.dat 





(3) 创建 空 的 Git 库 ， 使 用 Git 通 用 的 数据 迁移 命令 git fast-import 将 
cvs2git 的 导出 文件 寻 入 到 版 本 库 中 。 





$ mkdir test 

$ cd test 

$ git init 

$ cat ../git-blob.dat ../git-dump.dat | git fast-import 





(4) 检查 导出 结果 。 





$ git reset HEAD 

$ git checkout. 

$ git 10g -1 

commit 8334587cb241076bcd2e710b321e8e16b5e46bba 
Author: jiangxin <> 


Date: Tue Sep 21 07:56:31 2004 +0000 
修改 邮件 地 址 ; 
修改 搜索 引擎; 








很 好 ， 导 出 的 Git 库 日 志 中 ， 中 文 乱码 问题 已 经 解决 。 但 是 ， 提 交 
日 志 中 的 Author 对 应 的 提交 者 不 完整 :缺乏 邮件 地 址 。 这 是 因为 CVS 的 
提交 者 仅 为 用 户 登录 ID， 而 Git 的 提交 者 信息 还 要 包含 邮件 地 址 。 
cvs2git 提 供用 户 名 映射 的 方法 ， 不 过 不 能 使 用 命令 行 调用 cvs2git， 而 是 
要 通过 加 载 配 置 文件 来 运行 。 因 此 正式 进行 的 CVS 到 Git 版 本 库 转换 要 
采用 下 面 介绍 的 转换 方法 。 





34.3 ”有 版 本 库 转 换 





使 用 命令 行 参数 调用 cvs2git 麻 烦 、 可 重用 性 差 ， 而 且 可 配置 项 有 
限 。 采 用 cvs2git 配 置 文件 模式 运行 不 但 能 够 简化 cvs2git 的 命令 行 参数 ， 
而 且 还 能 够 提供 更 多 的 、 命 令 行 无 法 提供 的 配置 项 ， 可 以 更 精确 地 对 
CVS 到 Git 版 本 库 的 转换 进行 定制 。 





34.3.1 配置 文件 解说 


cvs2svn 软 件 包 提 供 了 一 个 cvs2git 的 配置 示例 文件 ， 见 源码 中 的 文件 


cvs2git-example.options (| 。 
将 该 示例 文件 在 本 地 复制 一 份 对 其 进行 更 改 。 该 文件 是 Python 代码 


格式 ， 以 “ 扩 〈 井 号 ) 开始 的 行 是 注释 ， 不 要 随意 更 改 文件 缩 进 ， 因 为 
缩 进 也 是 Python 语法 的 一 部 分 。 可 以 考虑 针对 下 列 的 选项 进行 定制 。 








(1) 设置 CVS 版 本 库 位 置 。 





使 用 配置 文件 方式 运行 cvs2git， 只 能 在 配置 文件 中 设置 要 转换 的 
CVS 版 本 库 位 置 ， 而 不 能 在 命令 行进 行 设置 。 具 体 来 襄 ， 是 在 配置 文件 
最 后 面 的 run_options 的 set_project 方 法 中 指定 。 








run_options,.set_project 


( 
# CVS 版 本 库 的 位 置 ( 不 是 工作 区 ， 而 是 包含 ，v 文件 的 版 本 库 ) 






























































# 可 以 是 版 本 库 下 的 子 目 录 。 


r'/cvshome/user/jiangxin/homepage/worldhello/archive/2003/', 





(2) 设置 导出 文件 的 位 置 。 


` 将 CVS 版 本 文件 的 内 容 导 出 至 blob 导 出 文件 : cvs2svn-tmp/git- 
blob.dat。 还 设置 了 使 用 更 稳定 的 “cvs ”命令 进行 导出 。 





ctx.revision collector = GitRevisionCollector( 
'cvs2svn-tmp/git-blob.dat', 
#RCSRevisionReader(co_executable=r'co'), 
CVSRevisionReader(cvs_ executable=r'cvs'), 


) 





另外 一 个 导出 文件 的 位 置 设 定 。 默 认 位 置 : cvs2svn-tmp/git- 
dump.dat。 





ctx.output_option = GitOutputOption( 
os.path.join(ctx.tmpdir, 'git-dump.dat'), 
# The blobs will be written via the revision recorder, so in 
# OutputPass we only have to emit references to the blob marks: 
GitRevisionMarkwriter(), 
# Optional map from CVS author names to git author names: 
author_transforms=author_transforms, 


) 











(2) 设置 无 提交 用 户 信息 时 使 用 的 用 户 名 。 这 个 用 户 名 可 以 用 接 
下 来 的 用 户 映 射 转换 为 Git 用 户 名 。 





ctx.username = "cvVS2SVvn' 





(3) 建立 CVS 用 户 和 Git 用 户 之 间 的 映射 。Git 用 户 名 可 以 用 Python 


的 元 组 (tuple) 语法 Cname，email) 或 字符 串 uname<email>' 1 来 表 


钞 。 





author_transforms={ 








'jiangxin' : ('Jiang Xin' "jiangxin@ossxp.com')， 
:dev1'， : U "开发 者 1 SS Com> '， 
'CVS2SVN' : 'CVS2svn <admin@example.com>', 





(4) 字符 集 编码 。 即 如 何 转 换 日 志 中 的 用 户 名 、 提 交 说 明 及 文件 
名 的 编码 。 


对 于 可 能 在 日 志 中 出 现 的 中 文 ， 必 须 做 出 与 下 面 类 似 的 设置 。 编 码 
的 顺序 对 输出 会 有 影响 ， 一 般 将 "utf8' 放 在 'gbk 之 前 ， 以 保证 当日 志 中 同 
时 出 现 两 种 编码 时 都 能 正常 转换 。《〈 这 是 因为 部 分 中 文 的 UTF8 编 码 在 
GBK 中 也 存在 着 古怪 的 对 应 。 





ctx.cvs_author_decoder = CVSTextDecoder( 


'utf8"', 
'gbk ' ， 


] ， 
fallpback_encoding= 'gbk' 
ctx.cvs_log decoder = CVSTextDecoder( 


'utf8"', 
'gbk ' ， 


] ， 
fallback_encoding="'gbk' 
ctx.cvs_filename decoder = CVSTextDecoder( 


'utf8"', 
'gbk ' ， 


] ， 
#fallback_encoding="'ascii' 





(5) 是 否 忽 略 .cvsignore 文 件 ? 默认 保留 .cvsignore 文 件 。 


无 论 选 择 保留 或 是 不 保留 ， 最 好 在 转换 后 手工 进行 .cvsignore 
到 .gitignore 的 转换 。 因 为 cvs2git 不 能 自动 将 .cvsignore 文 件 转换 
为 .gitignore 文 件 。 





ctx.keep_cvsignore = True 








(6) 对 文件 换行 符 等 的 处 理 。 下 面 的 配置 原本 是 针对 CVS 到 
Subversion 的 属性 转换 ， 但 是 也 会 影响 到 Git 转 换 时 的 换行 符 设 置 。 维 持 
默认 值 比 较 安全 。 





ctx.file_ property_setters.extend([ 
# 基于 配置 文件 设置 文件 的 mime 类 型 
#MimeMapper(r'/etc/mime.types', ignore case=False), 
# 对 于 二 进 制 文件 〈- kb 模式 ) 不 设置 svn:eol-style 属性 (对 于 Subversion 来 说 ) 
CVSBinaryFileEOLStyleSetter(), 
# 如 果 文件 是 二 进 制 ， 并 且 还 没有 设置 svn :mime-type， 将 其 设置 为 
'application/octet-stream'。 
CVSBinaryFileDefaultMimeTypeSetter(), 
# 如 果 希 望 根据 文件 的 mime 类 型 来 判断 文件 的 换行 符 ， 打 开 下 面 的 注释 
#EOLStyleFromMimeTypeSetter(), 
# 如 果 上 面 的 规则 没有 为 文件 设置 换行 符 类 型 ， 则 为 svn :eol-style 设置 默认 类 型 
# 〔 二 进 制 文件 除外 ) 
# 默 2 ` 为 其 设置 换行 符 类 型， 这 样 最 安全 
# 如 果 确 认 CVS 的 二 进 制 文件 都 已 经 设置 了 -kb 参数 ， 或 者 使 用 上 面 的 规则 能 够 对 
文件 类 型 做 出 正确 判断 ， 也 可 以 使 用 下 面 的 参数 为 非 二 进 制 文件 设置 默认 换行 符号 
## 'native' : 服务 器 端 文件 的 换行 符 保存 为 LE， 客户 端 根据 需要 自动 转换 
## 'CRLF': ”服务 器 端 文件 的 换行 符 保 存 为 CRLF， 客 户 端 亦 为 CRLF 
## 'CR': 服务 器 端 文件 的 换行 符 保存 为 CR， 客 户 端 亦 为 CR 
## 'LF': 服务 器 端 文件 的 换行 符 保存 为 LF， 客 户 端 亦 为 LF 
DefaultEOLStyleSetter (None), 
# 如 果 文 件 没有 设置 svn:eol-style ， 也 不 为 其 设置 svn:keywords 属性 
SVNBinaryFileKeywordsPropertySetter(), 
# 如 果 没 有 设置 svn :keywords， 基 于 文件 的 CVS 模式 进行 设置 。 
KeywordsPropertySetter(config,.SVN_ KEYWORDS_ VALUE), 
# 设置 文件 的 svn:executable 属性 ， 如 果 文 件 在 CVS 中 标记 为 可 执行 文件 。 
ExecutablePropertySetter(), 
]) 





































































































































































































































































































































































































































































































(7) 是 否 只 迁移 主线 ， 忽 略 分 文 和 里 程 碑 ”? 


默认 对 所 有 分 支 和 里 程 碑 都 进行 转换 。 如 果 选 择 忽 略 分 支 和 里 程 
碑 ， 则 将 False 修 改 为 True。 





ctx.trunk_only = False 





(8) 分 文 和 里 程 碑 的 迁移 及 转换 。 





global_symbol_strategy_rules = [ 
# 和 正则 表达 式 匹配 的 CVS 标识 ， 转 换 为 Git 的 分 支 
#ForceBranchRegexpStrategyRule(r'branch.*'), 
# 和 正则 表达 式 匹 配 的 CVS 标识 ， 转 换 为 Git 的 里 程 碑 
#ForceTagRegexpStrategyRule(r'tag.*'), 
# 忽略 和 正则 表达 式 匹配 的 CVS 标识 ， 不 进行 《到 Git 分 支 /里 程 碑 ) 转换 
ee unknown-.*"), 
# 有 歧义 的 CVS 标 识 的 处 理 选项 
# 默认 根据 使 用 频率 自动 确定 转换 为 分 支 或 里 程 碑 

HeuristicSstrategyRule(), 

# 或 者 全 部 转换 为 分 支 

#AllBranchRule( )， 

# 或 者 全 部 转换 为 里 程 碑 

#AllTagRule( )， 



























































































































































run_options.set_project( 


# A list of symbol transformations that can be used to rename 
symbols in this project. 
symbol_transforms=[ 
# 是否 需要 重新 命名 里 程 碑 ? 第 个 参数 用 于 匹配 ， 第 二 个 参数 用 于 葵 换 。 
# RegexpSymbolTransform(r'release-(\d+)_(\d+)', r'release-\1.\2'), 
# RegexpSymbolTransform(r'release-(\d+)_(\d+)_(\d+)', r'release-\1.\2.\3'), 

































































34.3.2 ”运行 cvs2git 完 成 转换 


参照 上 面 的 方法 ， 从 默认 的 cvs2git 配 置 文件 来 进行 定制 ， 在 本 地 创 
建 一 个 文件 〈 例 如 名 为 cvs2gitoptions 的 文件 ) 。 然 后 运行 cvs2git 完 成 版 
本 库 转 换 ， 有 具体 操作 步骤 如 下 。 


SS 


(1) 使 用 cvs2git 配 置 文件 ， 命 令 行 大 大 简化 了 。 





$ cvs2git --options cvs2git.options 





(2) 成 功 导出 后 ， 产 生 两 个 导出 文件 ， 都 保存 在 cvs2git-tmp 目 录 


一 个 保存 各 个 文件 的 各 个 不 同 版 本 的 数据 内 容 ， 即 命令 行 指定 的 输 
出 文件 git-blob.dat。 另 外 一 个 文件 是 上 面 命令 行 指定 的 gitrdump.dat， 用 
于 保存 各 个 提交 的 相关 信息 《提交 者 、 提 交 时 间 、 提 交 日 志 等 ) 。 


可 以 看 出 保存 文件 内 容 的 导出 文件 相对 更 大 一 些 。 





$ du -sh cvs2svn-tmp/* 
9.8M cvs2svn-tmp/git-blob.dat 
24K cvs2svn-tmp/git-dump.dat 





(3) 创建 空 的 Git 库 ， 使 用 Git 通 用 的 数据 迁移 命令 git-fast-import 将 
cvs2git 的 导出 文件 导入 到 版 本 库 中 。 





$ mkdir test 

$ cd test 

$ git init 

$ cat ../cvs2svn-tmp/git-blob.dat \ 
../CcVvs2svn-tmp/git-dump.dat | git fast-import 





(4) 检查 导出 结 





$ git reset HEAD 
$ git checkout. 
$ git 10g -1 


commit e3f12f57a77cbffcf62e19012507d041f1c9b03d 
Author: Jiang Xin <jiangxin@ossxp.com> 
Date: Tue Sep 21 07:56:31 2004 +0000 

修改 邮件 地 址 ; 

修改 搜索 引擎 ，; 














可 以 看 到 ， 这 一 次 的 转换 结果 不 但 使 得 日 志 中 的 中 文 可 以 显示 ， 而 
且 提 交 者 ID 也 转换 成 了 Git 的 风格 。 


[1] http:/ /repo.ort.cz/w/cvs2svn.git/blob/ HEAD:/cvs29git-example.options 


D] 字符 事前 面 的 字符 u 声 明 该 字符 囊 以 Unicode 格 式 保存 。 


34.4 ”迁移 后 的 版 本 库 检 查 


完成 迁移 还 不 能 算是 大 功 告 成 ， 还 需要 进行 细致 的 检查 。 
1. 文 件 名 和 日 志 中 的 中 文 


如 果 转 换 过 程 参考 了 前 面 的 步骤 和 注意 事项 ， 文 件 名 和 版 本 库 提交 
日 志 中 的 中 文 就 不 应 该 出 现 乱码 。 





2. 图 片 文件 被 破坏 


最 典型 的 错误 就 是 转换 后 部 分 图 片 被 破 坏 从 而 无 法 显示 。 这 是 怎么 
造成 的 呢 ? 





CVS 默 认 将 提交 的 文件 以 文本 方式 添加 ， 除 非 用 户 在 添加 文件 时 使 
用 了 -kb 参数 。 用 命令 行 提交 的 用 户 经 常会 忘记 使 用 -kb 参数 ， 这 就 导致 
一 些 二 进 制 文件 (如 图 片 文件 ) 以 文本 文件 的 方式 被 添加 到 其 中 。 文 本 
文件 在 CVS 检 入 和 检 出 时 会 进行 换行 符 转换 ， 在 服务 器 端 换行 符 保 存 为 
LF， 在 Windows 上 检 出 时 为 CRLF。 如 果 误 以 文本 文件 方式 添加 的 图 片 
中 恰好 出 现 了 CRLF， 则 在 Windows 上 似乎 没有 问题 (仍然 是 CRLF) ， 
但 是 CVS 库 转换 成 Git 库 后 ， 图 片 文件 在 Windows 上 再 检 出 时 ， 文 件数 据 
中 原来 的 CRLF 就 被 换 成 了 LF， 导 致 文件 被 破坏 。 





出 现 这 种 情况 是 CVS 版 本 库 的 使 用 和 管理 上 出 现 了 问题 ， 应 该 在 
CVS 版 本 库 中 对 有 问题 的 文件 重新 设置 属性 ， 标 记 为 二 进 制 文件 。 然 后 
再 进行 CVS 版 本 库 到 Git 库 的 转换 。 


3..cvsignore 文 件 的 转换 





CVS 版 本 库 中 可 能 存在 .cvsignore 文 件 用 于 设置 文件 忽略 ， 相 当 于 
Git 版 本 库 中 的 .gitignore。 因 为 当前 版 本 的 cvs2git 不 能 自动 将 .cvsignore 转 
换 为 .gitignore， 这 就 需要 在 版 本 库 迁移 后 手工 完成 。CVS 的 .cvsignore 文 
件 只 对 目录 内 的 文件 有 效 ， 不 会 同 下 作用 到 子 目录 上 ， 这 一 点 和 Git 
的 .gitignore 人 不同。 还 有 .cvsignore 文 件 每 一 行 都 用 空格 分 割 多 个 忽略 ， 而 
Git 的 每 个 忽略 单独 为 一 行 。 





4. 迁 移 后 的 测试 


一 个 简单 的 检查 方法 是 ， 在 同一 台 机 器 上 分 别 用 CVS 和 Git 检 出 
(或 克隆 ) ， 然 后 比较 本 地 的 差异 。 要 在 不 同 的 系统 上 (Windows、 


Linux) 分 别 进行 测试 。 








第 35 革 更 多 版 本 控制 系统 的 了 迁 


35.1 SVN 版 本 库 到 Git 的 迁移 


Subversion 版 本 库 到 Git 版 本 库 的 转换 ， 最 好 的 方法 就 是 git-svn。 而 

使 用 方法 在 前 面 “第 26 章 ”Git 和 SVN 协 同 模型 ”一 章 中 己 经 详细 

。 本 章 的 内 容 将 不 再 对 git-svn 的 用 法 做 过 多 的 重复 ， 只 在 这 里 强 

调 一 下 版 本 库 迁 移 时 的 注意 事项 ， 相 关 git-svn 的 内 容 还 请 参照 第 4 篇 “第 
26 章 ”Git 和 SVN 协 同 模型 ”。 





在 迁移 之 前 要 确认 一 个 问题 ，Subversion 转 换 到 Git 库 之 后 ， 
Subversion 还 能 继续 使 用 吗 ? 意思 是 说 还 允许 癌 Subversion 提 交 吗 ? 


如 果 回 答 是 ， 那 么 直接 查看 “第 26 章 Git 和 SVN 协 同 模型 "*， 用 Git 作 
为 前 端 工具 来 操作 Subversion 版 本 库 ， 而 不 要 理会 下 面 的 内 容 。 因 为 下 
面 描述 的 迁移 步骤 针对 的 是 Subversion 到 Git 版 本 库 的 一 次 性 的 迁移 。 





1. 不 在 提交 说 明 中 出 现 git-svn-id 标 识 


如 果 一 次 性 、 永 久 性 地 将 Subverison 迁 移 到 Git 库 ， 可 以 选择 “git- 
svn-id:” 标 识 不 在 转换 后 的 Git 的 提交 日 志 中 出 现 ， 这 样 根本 看 不 出 来 转 
换 后 的 Git 库 曾经 用 Subversion 版 本 库 维 护 过 


在 git-svn 的 clone 或 init 子 命令 行 中 使 用 参数 : --no-metadata。Git 库 的 
配置 会 自动 将 svn-remote.noMetadata 配 置 为 1。 之 后 执行 git svn fetch 时 束 


不 会 在 日 志 中 产生 “git-svn-id:” 标 识 。 





2.Subversion 用 户 名 到 Git 用 户 名 的 映射 


默认 转换 后 Git 库 的 提交 者 ID 为 如 下 格式 : userid<userid@SVN- 
REPOS-UUID>， 即 在 邮件 地 址 的 域名 处 以 SVN 版 本 库 的 UUID 代 奉 。 可 
以 在 执行 git svn fetch 时 ， 通 过 下 面 的 参数 提供 一 个 映射 文件 完成 SVN 用 
户 名 到 Git 用 户 名 的 转换 。 





-A<filename>, --authors-file=<filename> 





即 用 -A 或 --authors-file 参 数 给 出 一 个 映射 文件 ， 这 个 文件 帮助 git-svn 
将 Subversion 用 户 名 映射 为 Git 用 户 名 。 此 文件 的 每 一 行 定义 一 个 用 户 名 
了 映射 ， 每 一 行 的 格式 为 : 





lJoginname = User Name <user@example.com> 





也 可 以 通过 下 面 的 命令 在 Git 库 的 config 文 件 中 设置 ， 这 样 就 不 必 在 


每 次 执行 git svn fetch 时 都 带 上 这 个 参数 。 





$ git config svn.authorsfile /path/to/authersfile 





当 设 定 了 用 户 映 射 文件 后 ， 如 果 在 执行 git svn fetch 时 发 现 SVN 的 用 


户 在 该 映射 文件 中 没有 定义 ， 转 换 过 程 被 中 断 。 需 要 重新 编辑 用 户 映 射 
文件 ， 补 充 新 的 用 户 映 射 后 ， 再 重新 执行 gitrsvn 命 令 


3. 里 程 碑 和 分 支 的 转换 


使 用 默认 的 参数 执行 SVN 到 Git 的 转换 时 ，SVN 的 里 程 碑 和 分 支 转 
换 到 Git 库 的 refsxremotes 引 用 下 。 这 会 导致 其 他 人 从 转换 后 的 Git 库 殉 隆 
时 ， 看 不 到 Subversion 原 有 的 分 支 和 里 程 碑 。 


当 以 默认 的 参数 执行 git svn init 时 ，Git 的 配置 文件 中 会 生成 下 面 的 
配置 : 





[svn-remote "svn" 
fetch = trunk:refs/remotes/trunk 
branches = branches/*:refs/remotes/* 
tags = tags/*:refs/remotes/tags/* 





可 以 直接 编辑 Git 配 置 文件 ， 将 其 内 容 调 整 如 下 : 





[svn-remote "svn" 
fetch = trunk:refs/heads/master 
branches = branches/*:refs/heads/* 
tags = tags/*:refs/tags/* 





之 后 ， 再 执行 git svn fetch 后 ， 就 可 以 实现 SVN 的 分 文 和 里 程 牌 正确 
地 转换 为 Git 库 的 里 程 碑 。 人 个 则 如 有 果 不 对 Git 配 置 文件 作出 调整 ， 就 需要 
手动 将 .git/refs/remots/ 下 的 引用 移动 到 .git/refs/heads 及 .git/refs/tags 下 。 


4. 清 除 git-svn 的 中 间 文 件 


git-svn 的 中 间 文 件 位 于 目录 .gitysvn 下 ， 删 除 此 目录 完成 对 git-svn 转 
换 数据 库 文 件 的 清理 。 


35.2 Hg 版 本 库 到 Git 的 迁移 


Mercurial 〈 水 银 ) 是 和 Git 同 时 代 的 、 与 之 齐名 的 一 球 闭 名 的 分 布 
式 版 本 控制 系统 ， 也 有 相当 多 的 使 用 者 。 惑 像 水 银 又 名 未 一 样 ， 作 为 版 
本 控制 系统 的 Mercurial 又 称 作 Hg 水 银元 素 符 号 ) 。Hg 具 有 简单 易 用 
的 优点 ， 至 少 Hg 按 提交 的 顺序 递增 的 数字 编号 让 Subversion 用 户 感 到 更 
为 杀 切 。Hg 的 开发 语言 除 少 部 分 因 性 能 原因 使 用 C 语 言 外 ， 大 部 分 用 
Python 语言 开发 完成 ， 因 而 更 易 扩 展 ， 最 终 形 成 了 Hg 最 具 特 色 的 插件 系 
统 。 例 如 MQ 束 是 Hg 一 个 很 有 用 的 插件 ， 通 过 Quilt 式 的 补丁 集 实现 对 定 
制 开发 的 特性 分 支 的 版 本 控制 ， 当 然 StGit 和 Topgit 也 可 以 实现 类 似 的 功 


全 已 
月 上 。 





但 是 Hg 存在 一 些 不 足 。 例 如 服务 器 的 存储 效率 不 能 和 Git 相 比 ， 服 
务 器 存储 空间 占用 更 大 。Hg 还 不 支持 真正 的 分 支 ， 所 以 不 能 向 git-svn 那 
样 完 整地 对 Subversion 版 本 库 进 行 转换 和 互 操作 。Hg 的 提交 只 能 回 退 一 
次 ， 要 想 多 次 回 退 和 整理 版 本 库 需 要 用 到 MQ 插件 。 作 为 定制 开发 的 利 
器 ，Hg+MQ 不 适合 多 人 协作 开发 而 Gitt+Topgit 更 为 适合 。 





不 论 是 何 原因 如 果 想 从 Hg 迁移 到 Git， 用 一 个 名 为 fast-export 的 转换 
工具 就 可 以 很 方便 地 实现 。fast-export 是 一 个 用 Python 开 发 的 命令 行 工 
有 具 ， 可 以 将 本 地 的 Hg 版 本 库 迁 移 为 Git 版 本 库 。 其 原理 和 CVS 版 本 库 迁 








移 全 Git 时 使 用 的 cvs2git 相 仿 ， 都 是 先 从 源 版 本 库 生 成 导出 文件 ， 再 用 
Git 的 通用 版 本 库 转换 工具 git-fast-import 导 入 到 新 建 的 Git 版 本 库 中 。 


安装 fast-export 非 常 简 单 ， 只 要 用 Git 元 隆 fast-export 的 版 本 库 即 可 。 


$ cd /path/to 
$ git clone git://repo.or.cz/fast-export.git 


完成 克隆 后 ， 会 看 到 /path/to/fast-export 目 录 中 有 一 个 名 为 hg-fast- 
import.sh 的 脚本 文件 ， 该 文件 封 狼 了 对 相应 Python 脚 本 的 调用 。 使 用 该 
脚本 可 以 实现 Hg 版 本 库 到 Git 版 本 库 的 迁移 。 


下 面 就 演示 一 下 Hg 版 本 库 到 Git 版 本 库 的 转换 ， 具 体操 作 过 程 如 
Fs 


(1) 要 转换 的 Hg 版 本 库 位 于 路 径 /path/to/hg/hello/.hg 下 。 








Hg 个 文 持 真正 的 分 文 ， 而 且 版 本 库 中 可 能 存在 尚未 合并 的 多 个 头 
旨 针 。 检 查 一 下 不 要 存在 具有 相同 分 文 名 但 尚未 合并 的 多 个 头 指针 ， 人 否 
则 转换 会 失败 。 下 面 显 示 的 该 Hg 版 本 库 中 具有 两 个 具名 分 文 r1.x 和 
next， 还 有 一 个 默认 的 未 设置 名 称 的 头 指 针 ， 因 为 分 文 名 各 不 相同 所 以 
不 会 为 转换 过 程 造 成 嘛 烦 。 














$ hg heads 

修改 集 : 7:afdd475caeee 
分 文 

标签 : tip 

父亲 : 0:798a9568e10e 




















用 户 : Jiang Xin <jiangxin@ossxp.com> 




























































































日 期 : Fri Jan 14 17:01:47 2011 +0800 

描述 : 

start new branch: ri.x 

医改 集 : 6:7f5a46201dda 

分 文 : next 

用 户 : Jiang Xin <jiangxin@ossxp.com> 

日 期 : Fri Jan 14 17:01:04 2011 +0800 

文件 ; src/locale/zh_CN/LC_ MESSAGES/helloworld.po 
imported patch 100_locale zh _cn.patch 

区 改 集 : 1:97f0a21021c6 

用 户 : Jiang Xin <worldhello.net AT gmail DOT com> 
日 期 : Sun Aug 23 23:53:05 2009 +0800 

文件 : Src/COPYRIGHT src/main.bak src/main.c 

描述 : 




















Fixed #6: import new upstream version hello-2.0.0 








(2) 初始 化 一 个 Git 版 本 库 ， 该 版 本 库 就 是 迁移 的 目标 版 本 库 。 





$ mkdir -p /path/to/my/workspace/hello 

$ cd /path/to/my/workspace/hello 

$ git init 

Initialized empty Git repository in /path/to/my/workspace/hello/.git/ 





(3) 在 刚刚 完成 初始 化 的 Git 工 作 区 中 调用 hg-fast-export.sh 脚 本 完 
成 版 本 库 转换 。 





$ /path/to/fast-export/hg-fast-export.sh -r /path/to/hg/hello 








(4) 转换 完毕 ， 执 行 git branch 会 看 到 Hg 版 本 库 中 的 具名 分 支 都 被 
转换 为 相应 的 分 支 ， 没 有 命名 的 默认 头 指针 被 转换 为 master 分 支 。 





$ git branch 
* master 
next 
ri.x 








在 转换 后 的 Git 版 本 库 目 录 中 ， 保 存 了 儿 个 用 于 记录 版 本 库 转 换 进 


度 的 状态 文件 (.giVhg2git-*) ， 当 在 Git 工 作 区 不 带 任何 参数 执行 hg- 
fast-export,sh 命 令 时 ， 会 继续 进行 增 量 式 的 转换 ， 将 Hg 版 本 库 中 的 新 提 
交 迁 移 到 Git 版 本 库 中 。 


如 末 使 用 了 多 个 不 同 的 Hg 元 隆 版 本 库 进行 分 文 管理 ， 束 需要 对 Hg 
版 本 库 逐 一 进行 转换 ， 然 后 再 对 转换 后 的 Git 版 本 库 进行 合并 。 在 合并 
Git 版 本 库 的 时 候 可 以 参考 下 面 的 命令 。 





$ git remote add <name1> <path/to/repos/1> 

$ git remote add <name2> <path/to/repos/2> 

$ git remote update 

$ git checkout -b <branch1> origin/<name1>/master 
$ git checkout -b <branch2> origin/<name2>/master 





35.3 ”通用 版 本 库 迁 移 


如 采 在 前 面 的 迁移 方案 中 没有 涉及 您 的 版 本 控制 工具 ， 也 不 要 紧 ， 
因为 很 可 能 通过 搜索 引擎 就 能 找到 一 球 合 适 的 迁移 工具 。 如 末 找 不 到 相 
应 的 工具 ， 可 能 是 你 使 用 的 版 本 控制 工具 太 冷 门 ， 或 者 是 一 球 不 提供 迁 
移 接口 的 商业 版 本 控制 工具 器 。 这 时 你 可 以 通过 手工 检 入 的 方式 ， 或 
者 针对 Git 提 供 的 版 本 库 导入 接口 git-fast-import 实 现 版 本 库 导 入 。 





手工 检 入 的 方式 适合 于 只 有 少数 几 个 提交 ， 或 者 对 大 部 分 提交 历史 
不 关心 而 只 需要 对 少数 里 程 碑 版 本 执行 导入 的 版 本 库 叶 入 。 这 种 版 本 库 
迁移 方式 非 第 简单， 相当 于 在 完成 Git 版 本 库 初 始 化 后 ， 在 工作 区 重复 
执行 : 工作 区 文件 清理 (rm-rf) ， 文 件 复制 ， 执 行 git add-A 添 加 到 暂 存 


区 ， 执 行 git commit 提 交 。 


但 是 如 果 需 要 将 版 本 库 完 整 的 历史 全 部 迁移 到 新 的 Git 版 本 库 中 ， 
手工 检 入 的 方法 就 不 可 取 了 ， 针 对 git-fast-import 的 编程 将 是 一 个 好 的 方 
法 。Git 提 供 了 一 个 通用 的 版 本 库 导 入 解决 方案 ， 即 通过 向 命令 git fast- 
import 传 递 特定 格式 的 字 节 流 ， 就 可 以 实现 Git 版 本 库 的 创建 。 工 具 git- 
fast-import 的 导入 文件 格式 设计 得 相对 比较 简单 ， 当 理解 了 其 格式 约定 
后 ， 可 以 相对 容易 地 开发 出 针对 特定 版 本 库 的 迁移 工具 。 





1. 数 据 混杂 在 提交 中 的 导入 文件 











下 面 就 是 一 个 简单 的 导入 文件 ， 为 说 明 方便 在 前 面 标注 了 行 号 ， 将 
这 个 文件 保存 为 /path/to/file/dump1.dat。 





commit refs/heads/master 
mark :1 

committer USser1 <user1i@ossxp.com> 1295312699 +0800 
data <<EOF 

My initial commit. 

EOF 

M 644 inline README 

data <<EOF 

Hello, world. 

10 EOF 

M 644 inline team/user1.txt 
data <<EOF 

I'm useri1. 

EOF 


‘OONOPRODP 


PP 
人 上 WwW N 上 





上 面 这 段 文字 应 该 这 样 理 解 : 


第 1 行 以 commit 开 头 ， 标 记 一 个 提交 的 开始 。 该 提交 会 创建 (或 


更 新 ) 引用 refs/heads/master。 


- 第 2 行 以 mark 开 头 ， 是 一 个 标记 指令 ， 将 这 个 提交 用 “:1” 标 示 以 


方便 后 面 的 提交 参照 。 


. 第 3 行 记录 了 这 个 提交 的 提交 者 是 Userl ， 邮 件 地 址 为 


<user1(Q@ossxp.com>>， 提 交 时 间 则 采用 Unix 时 间 格 式 。 


` 第 4~6 行 是 该 提交 的 提交 说 明 ， 提 交 说 明 用 data 数 据 块 的 方式 进 


“ 第 4 行 在 data 语 句 后 紧 接着 的 <<EOF 含 义 为 data 的 内 容 到 以 EOF 


标记 的 行 截止 。 这 样 的 表示 法 称 为 “Here document” 表 示 法 上 站。 


.第 7 行 以 字母 M 开 头 ， 含 义 是 修改 (或 新 建 ) 了 一 个 文件 ， 文 件 
名 为 README ， 而 文件 的 内 容 以 ihline 的 方式 提供 。 


第 8~10 行 则 是 以 内 联 (inline) 数据 块 的 方式 提供 README 文 件 


的 内 容 。 


" 第 11 行 定义 了 该 提交 修改 的 第 二 个 文件 team/userl.txt。 该 文件 的 


内 容 也 是 以 内 联 (inline) 的 方式 给 出 。 
. 第 12~14 行 给 出 文件 team/user1.txt 的 内 容 。 


下 面 初始 化 一 个 新 的 版 本 库 ， 并 通过 导入 文件 /path/to/file/dump1.dat 
的 方式 为 版 本 库 注入 数据 ， 操 作 步 又 如 下 。 


(1) 初始 化 版 本 库 。 





$ mkdir -p /path/to/my/workspace/import 
$ cd /path/to/my/workspace/import 
$ git init 





(2) 调用 git fast-import 命 令 。 





$ git fast-import < /path/to/file/dump1.dat 
git-fast-import statistics: 


Alloc'd objects: 5000 

Total objects: 5 (人 0 duplicates ) 
blobs : 2 (人 9 duplicates 0 deltas) 
trees 2 (人 0 duplicates 0 deltas) 
commits: 工人 0 duplicates 0 deltas) 


tags ©( 0 duplicates 0 deltas) 
Total branches : 工人 1 loads ) 
marks: 1024 ( 1 unique ) 
atoms: 3 
Memory total: 2344 KiB 
pools : 2110 KiB 
objects : 234 KiB 
pack_report: getpagesize() 4096 
pack_report: core,packedGitwWindowSize 1073741824 
pack_report: core.packedGitLimit 8589934592 


pack_report: pack_used_ctr = 1 


pack_report: pack_mmap_calls 1 
pack_report: pack_open_windows 1/ 1 
pack_report: pack_mapped 323 / 323 





(3》 看 看 提交 目 志 。 





$ git 1og --pretty=fuller --stat 
commit 18f4310580ca915d7384b116fcb2e2ca0b833714 


Author: User1 <useri@ossxp.com> 
AuthorDate: Tue Jan 18 09:04:59 2011 +0800 
Commit: User1 <useri@ossxp.com> 


CommitDate: Tue Jan 18 09:04:59 2011 +0800 
My initial commit. 
README | 1 + 
team/user1.txt | 1+ 
2 files changed, 2 insertions(+), 0 deletions(-) 





2.Eblobrh 和 定义 数 据 间 征 提 到 中 下 用 的 导入 文件 


再 来 看 一 个 导入 文件 。 将 下 面 的 内 容 保存 到 文 
件 /path/to/file/dump2.dat 中 。 





blob 

mark :2 

data 25 
Hello, world. 
Hi, User2 . 
blob 

mark :3 

data <<EOF 
I'm user2. 
EOF 

commit refs/heads/master 
mark :4 


2 
OO 四 om”~ODOA 上 wwN 忆 


上 忆 
Dp 


13 committer User2 <user2@ossxp.com> 1295312799 +0800 
14 data <<EOF 

15 User2's test commit. 

16 EOF 

17 from :1 

18 M 644 :2 README 

19 M 644 :3 team/user2.txt 








上 面 的 内 容 为 了 说 明 方 便 标注 了 行 写 ， 注 意 不 要 把 行 写 也 代入 文件 


“第 1~5 行 定义 了 编号 为 :2 的 文件 内 容 。 该 文件 的 内 容 共 有 25 
个 字 节 ， 第 3 行 开始 的 data 文 字 块 通过 在 后 面 跟 上 一 个 表示 文件 长 度 的 十 
数字 界定 了 内 容 的 起 止 。 


. 第 6~10 行 定义 了 编号 为 “3” 的 文件 内 容 。 第 8 行 界定 该 文件 内 
容 使 用 了 “here document” 的 语法 ， 使 用 “here document” 语 法 比较 适 


合 于 文本 内 容 ， 使 用 内 容 长 度 标示 内 容 起 止 更 适合 于 二 进 制 文件 。 
: 第 11 行 开始 定义 了 一 个 新 的 提交 。 
` 第 12 行 设 定 该 提交 的 编号 为 “:4”。 


. 第 17 行 以 from 开 头 ， 定 义 了 编号 为 “:1” 的 提交 是 该 提交 的 父 提 


交 ， 即 在 /path/to/fle/dump1.dat 中 定义 的 提交 。 


第 18 行 和 第 19 行 设 定 了 该 提交 更 改 的 两 个 文件 ， 这 两 个 文件 的 内 
容 不 像 之 前 的 导出 文件 “dump1.dat” 那 样 使 用 内 联 方式 定义 内 容 ， 而 是 
采用 引用 方式 引用 前 面 定义 的 blob 文 字 块 作为 文件 的 内 容 。 


如 果 以 增 量 方式 导入 dump2.dat 会 报错 ， 因 为 在 第 17 行 引用 的 “:1? 没 
有 定义 。 





$ git fast-import < /path/to/file/dump2.dat 
fatal: mark :1 not declared 
fast-import: dumping crash report to .git/fast_ import_crash 21772 








如 果 将 文件 /path/to/file/dump2.dat 的 第 17 行 的 引用 修改 为 提交 ID， 
就 可 以 增 量 导入 了 。 不 过 ， 为 了 说 明 的 方便 ， 还 是 通过 将 两 个 导入 文件 
一 次 性 传递 给 git fast-import 来 创建 一 个 新 版 本 库 ， 操 作 步 骤 如 下 。 








(1) 初始 化 版 本 库 import2。 





$ mkdir -p /path/to/my/workspace/import2 
$ cd /path/to/my/workspace/import2 
$ git init 





(2) 调用 git fast-import 命 令 。 





$ cat /path/to/file/dumpi.dat \ 
/path/to/file/dump2.dat | git fast-import 





(3) 导入 之 后 的 日 志 显 示 : 





$ git 1og --graph --stat 

* commit 73a6f2742f9da7c1b4bb8748e018a2becad39dd6 
| Author: User2 <user2@ossxp.com> 

| Date: Tue Jan 18 09:06:39 2011 +0800 


User2's test commit. 


team/user2.txt | 1+ 


| 

| 

| 

| README | 1+ 

| 

| 2 files changed, 2 insertions(+), © deletions(-) 
| 


* commit 18f4310580ca915d7384b116fcb2e2ca0b833714 


Author: User1 <user1i@ossxp.com> 
Date: Tue Jan 18 09:04:59 2011 +0800 


My Initial commit. 
README | 1+ 
team/user1.txt | 业 , 村 
2 files changed, 2 insertions(+)， 0 deletions(-) 





3. 包 含 了 合并 提交 及 里 程 碑 的 导入 文件 





下 面 再 来 看 一 个 导入 文件 ， 在 这 个 导入 文件 中 ， 包 含 了 合并 提交 ， 


以 及 创建 里 程 碑 。 





‘ONORODP 


blob 

mark :5 

data 25 

Hello, world. 

Hi, User1l. 

blob 

mark :6 

data 35 

Hello, world. 

Hi, user1 and user2. 
commit refs/heads/master 
mark :7 

committer USser1 <user1i@ossxp.com> 1295312899 +0800 
data <<EOF 

Say helo to useril. 

EOF 

from :1 

M 644 :5 README 

commit refs/heads/master 
mark :8 

committer User2 <user2@0ossxp.com> 1295312900 +0800 
data <<EOF 

Say helo to both users. 
EOF 

from :4 

merge :7 

M 644 :6 README 

tag refs/tags/vi1.0 

from :8 

tagger Jiang Xin <jiangxin@ossxp.com> 1295312901 +0800 
data <<EOF 

Version v1.0 

EOF 





将 这 个 文件 保存 到 /path/to/file/dump3.dat 中 。 下 面 就 针对 该 文件 内 容 


进行 简要 的 说 明 : 


. 第 1~5 行 和 第 6~10 行 定义 了 两 个 blob 对 和 象 ， 代 表 了 对 README 文 
件 的 两 个 不 同 的 修改 。 

. 第 11 行 开始 定义 了 编号 为 “:7 的 提交 。 从 第 17 行 可 以 看 出 该 提 
交 的 父 提交 也 是 由 dump1.dat 导 入 的 第 一 个 提交 。 

` 第 19 行 开始 定义 了 编号 为 “:8” 的 提交 。 该 提交 为 一 个 合并 提 
交 ， 除 了 在 第 25 行 设 定 了 第 一 个 父 提 交 外 ， 还 由 第 26 行 给 出 了 第 二 个 父 


提交 。 


. 第 28 行 开始 定义 了 一 个 里 程 碑 。 里 程 碑 的 名 字 为 tefs/tags/v1.0。 
第 29 行 指 定 了 该 里 程 碑 对 应 的 提交 。 里 程 碑 的 说 明 由 第 31~33 行 的 指令 
给 


下 面 将 之 前 的 三 个 导入 文件 一 次 性 传递 给 git fast-import 来 创建 一 个 
新 版 本 库 ， 操 作 步 又 如 下 。 


(1) 初始 化 版 本 库 import3。 





$ mkdir -p /path/to/my/workspace/import3 
$ cd /path/to/my/workspace/import3 
$ git init 





(2) 调用 git fast-import 命 令 。 





$ cat /path/to/file/dumpi1.dat /path/to/file/dump2.dat \ 
/path/to/file/dump3.dat | git fast-import 





(3) 查看 创建 的 版 本 库 的 日 志 。 


从 日 志 中 可 以 看 出 里 程 碑 v1.0 已 经 建立 在 最 新 的 提交 上 了 。 





$ git log --oneline --graph --decorate 
a47790e (HEAD, tag: refs/tags/v1.90, master) Say helo to both users. 
\ 
* f486a44 Say helo to useri. 
| 73a6f27 User2's test commit. 


大 
| 
| 

* 
| 

大 


18f4310 My initial commit. 





理解 了 git-fast-import 的 导入 文件 格式 ， 针 对 特定 的 版 本 控制 系统 开 
肥 一 个 新 的 迁移 工具 就 不 是 难事 了 。Hg 的 迁移 工具 fast-export 就 是 一 个 
很 好 的 参照 。 


[1 ”实际 上 Linux 版 本 控制 系统 迁移 到 Git 时 ， 最 早 也 没有 工具 帮助 迁移 
Bitkeeper 中 的 历史 代码 。 关 于 Linux 如 何 利 用 嫁接 (Grafts) 实现 新 旧 
Linux 版 本 控制 系统 的 对 接 参 见 本 书 第 8 篇 第 41 章 “41.4 嫁 接 和 替换 小 
节 的 相关 内 容 。 


[2] http:/ /en.wikipedia.org/wiki/ Here_document 


35.4 ”Git 版 本 库 整 理 
Git 提 供 了 太 多 武器 进行 版 本 库 的 整理 ， 可 以 将 一 个 Git 版 本 库 改 头 
换 面 成 另外 一 个 Git 版 本 库 。 


. 使 用 交互 式 变 基 操 作 ， 将 多 个 提交 合并 为 一 个 (参见 第 2 篇 第 12 


章 “12.3.3 时 间 旅 行 三 ”小 节 ) 。 


“ 使 用 StGit， 合 并 提交 及 更 改 提交 (参见 第 3 篇 第 20 


章 “20.3.1StGit” 小 节 ) 。 


` 借助 变 基 操 作 ， 抛 弃 部 分 历史 提交 (参见 第 2 篇 第 12 章 “12.4 丢 弃 


历史 小 节 ) 。 


. 使 用 子 树 合并 ， 将 多 个 版 本 库 整 合 在 一 起 (参见 第 4 篇 “第 24 
章 子 树 合并 ”) 。 


. 使 用 gitsubttee 播 件 ， 将 版 本 库 的 一 个 目录 拆 分 出 来 成 为 独立 版 本 
库 的 根 目 录 (参见 第 4 篇 第 24 章 “24.5.4git subtree split” 小 节 ) 。 





但 是 有 些 版 本 库 重 整 工作 如 果 使 用 上 面 的 工具 会 非常 困难 ， 而 采用 
另外 一 个 还 没有 被 用 到 的 Git 命 令 git filter-branch 却 可 以 做 到 事半功倍 。 
看 看 使 用 这 个 新 工具 来 实现 下 面 的 这 几 个 任务 是 多 么 的 简单 和 优美 。 


(1) 将 版 本 库 中 某 个 文件 彻底 删除 趾 。 即 凡是 有 该 文件 的 提交 都 
逐一 做 出 修改 ， 撤 出 该 文件 。 





$ git filter-branch --tree-filter "rm -f filename' -- --all 





(2) 更 改 历 史 提 交 中 茶 一 提交 者 的 姓名 及 邮件 地 址 。 





$ git filter-branch --commit-filter ' 

If [ "$6GIT_AUTHOR_NAME" = "Xin Jiang" ]; then 
GIT_AUTHOR_NAME="Jiang Xin" 
GIT_AUTHOR_EMAIL="jiangxin@ossxp.com" 
GIT_COMMITTER_ NAME="$GIT_ AUTHOR_NAME" 
GIT_COMMITTER_EMAIL="$GIT AUTHOR_EMAIL" 

fi 

git commit-tree "$@"; 

”HEAD 





(3) 为 没有 包含 签名 的 历史 提交 添加 签名 。 





$ git filter-branch -f --msg-filter ' 
signed=false 
while read line; do 
if echo $line | grep -q Signed-off-by; then 
signed=true 
fi 
echo $line 
done 
if ! $signed; then 
echo Wr 
echo "Signed-off-by: YourName <your@email.address>" 





通过 上 面 的 例子 ， 可 以 看 出 命令 git filter-branch 针 对 不 同 的 过 滤器 
提供 可 执行 脚本 ， 从 不 同 的 角度 对 Git 版 本 库 进 行 重 构 。 该 命令 的 用 法 
如 下 : 





git filter-branch [--env-filter <command>] [--tree-filter <command>] 
[--index-filter <command>] [--parent-filter <command>] 
[--msg-filter <command>] [--commit-filter <command>] 
[--tag-name-filter <command>] [--subdirectory-filter <directory>] 
[--prune-empty] 
[--original <namespace>] [-d <directory>] [-f | --force] 
[--] [<rev-list options>...] 





数 是 用 于 提供 不 同 接口 的 ， 因 此 


站 


这 条 命令 寞 第 复杂 ， 但 是 大 部 分 


还 是 比较 好 理解 的 。 


=) 


` 该 命令 最 后 的 <rev-list> 参 数 提供 要 修改 的 版 本 范围 ， 如 果 省 略 则 
相当 于 HEAD 指 向 的 当前 分 支 。 也 可 以 使 用 --all 来 指 代 所 有 引用 ， 但 是 
要 在 --al 和 前 面 的 参数 间 使 用 分 隔 符 “-- 。 


` 运行 git filter-branch 命 令 改 写 分 支 之 后 ， 被 改写 的 分 支 会 在 
refs/original 中 对 原始 引用 做 备份 。 对 于 在 refs/original 中 己 有 备份 的 ， 
命令 拒绝 执行 ， 除 非 使 用 -f 或 --force 参 数 。 


其 他 的 后 面 可 带 命 令 脚 本 <command> 的 参数 (如 --env- 
filter<command>>) ， 为 git filter-branch 命 令 提 供 相 应 的 编程 接口 ， 从 不 同 
的 角度 实现 对 Git 版 本 库 的 过 滤 。 下 面 针 对 各 个 过 滤器 分 别 进行 介绍 。 





35.4.1 “环境 变量 过 滤器 





参数 --env-filter 用 于 设置 一 个 环境 变量 过 滤器 。 该 过 滤 喜 用 于 修改 
环境 变量 ， 对 特定 的 环境 变量 的 修改 会 改变 提交 。 下 面 的 示例 可 用 于 修 
改作 者 /提交 者 的 邮件 地 址 总 。 











有 一 


$ git filter-branch --env-filter ' 
an="$GIT_AUTHOR_NAME" 
am="$GIT_AUTHOR_EMAIL" 
cn="$GIT_COMMITTER_NAME" 
cm="$GIT_COMMITTER_EMAIL" 
if [ "$cn" = "Kanwei Li" ]; then 
cm="kanwei@gmail.com" 


fi 

If [ "$an" = "Kanwei Li" ]; then 
am="kanwei@gmail.com" 

fi 


export GIT_AUTHOR_EMAIL=$am 
export GIT_COMMITTER_EMAIL=$cm 
1 





这 个 示例 和 本 市 一 开始 介绍 的 更 改作 者 /提交 者 信息 的 示例 功能 相 
同 ， 但 是 使 用 了 不 同 的 过 滤器 ， 你 可 以 根据 喜好 目 由 选择 。 








35.4.2” 树 过 滤器 


参数 --tree-filter 用 于 设置 树 过 涯 器 。 树 过 滤器 会 将 每 个 提交 检 出 到 
特定 的 目录 中 《〈.gitrrewrite/ 目 录 ， 或 者 用 -d 参 数 指定 的 目录 ) ， 针 对 检 
出 目录 中 文件 的 修改 、 添 加 、 删 除 会 改变 提交 。 注 意 此 过 滤器 久 
略 .gitignore， 因 此 对 检 出 目录 的 任何 修改 都 会 记录 在 新 的 提交 中 。 之 前 
介绍 的 文件 删除 就 是 一 例 ， 再 比如 对 文件 名 的 修改 : 





$ git filter-branch --tree-filter ' 
[ -f oldfile ] && mv oldfile newfile || true 
- --all 





35.4.3” 暂 存 区 过 滤器 


树 过 滤器 因为 要 将 每 个 提交 检 出 ， 因 此 非常 费时 ， 而 参数 --index- 
filter 给 出 的 暂 存 区 过 滤 占 则 没有 这 个 缺 皮 。 如 果 将 之 前 使 用 树 过 滤器 删 
除 文件 的 操作 换 成 用 暂 存 区 过 滤器 来 实现 ， 将 会 运行 得 更 快 。 





$ git filter-branch --index-filter ' 
git rm --cached --ignore-unmatch filename 
- --all 








其 中 参数 --ignore-unmatch 让 git rm 命令 不 至 于 因为 暂 存 区 中 不 存在 
filename 文 件 而 失败 。 





3544 ” 父 节 点 过 小 大 


参数 --parentrfilter 用 于 设置 父 节 点 过 滤器 ， 该 过 滤器 用 于 修改 提交 
的 父 节 点 。 提 交 原 始 的 父 节 后 通过 标准 输入 传 入 脚本 ， 而 脚本 的 输出 将 
作为 提交 的 新 的 父 节 皮 。 父 节操 参数 的 格式 为 ， 如 果 没 有 父 刷 氮 《〈 初 始 
提交 ) 则 为 空 ， 如 果 有 一 个 父 节 点 ， 参 数 为 “<-p parent”; 如 果 是 合并 提 


交 ， 则 有 多 个 父 节 点 ， 参 数 为 “-p parent1-p parent2-p parent3...”。 


下 面 的 命令 将 当前 分 文 的 初始 提交 尹 接 到 <graft-id> 所 指 同 的 提交 
se 





$ git filter-branch --parent-filter 'sed "s/^\$/-p <graft-id>/"' HEAD 





如 果 不 是 将 初始 提交 (没有 父 提 交 ) 而 是 任意 的 一 个 提交 妈 接 到 男 


外 的 提交 上 ， 可 以 通过 GIT_COMMIT 环 境 变量 对 提交 进行 判断 ， 更 改 
其 父 节点 以 实现 嫁接 。 





$ git filter-branch --parent-filter \ 
"test $GIT_COMMIT = <commit-id> && \ 
echo "-p <graft-id>" || cat 
”HEAD 





关于 嫁接 ，Git 可 以 通过 配置 文件 .giUVinfo/grafts 来 实现 中 ， 而 git 
filter-branch 命 令 可 以 基于 该 配置 文件 对 版 本 库 实现 永久 性 的 更 改 。 











$ echo "$commit-id $graft-id" >> .git/info/grafts 
$ git filter-branch $graft-id. .HEAD 





35.4.5 ”提交 说 明 过 滤器 


参数 --msg-filter 用 于 设置 提交 说 明 过 滤器 。 该 过 滤器 用 于 改写 提交 
说 明 。 原 始 的 提交 说 明 作为 标准 输入 传 入 脚本 ， 而 脚本 的 输出 则 作为 新 
的 提交 说 明 。 


例如 ， 使 用 git-svn 命 令 从 Subversion 迁 移 过 来 的 Git 版 本 库 ， 默 认 情 
况 下 在 提交 说 明 中 包含 git-svn-id: 字 样 的 说 明 ， 如 果 需 要 将 其 清除 ， 可 以 
不 必 重 新 迁移 ， 而 是 使 用 下 面 的 命令 重 写 提交 说 明 。 








$ git filter-branch --msg-filter 'sed -e "/^git-svn-id:/d"' -- --all 





再 如 ， 为 最 新 的 10 个 提交 添加 “Acked-by:” 格 式 的 签名 。 





$ git filter-branch --msg-filter ' 
Cat && 
echo "Acked-by: Bugs Bunny <bunny@bugzilla.org>" 
”HEAD~10. .HEAD 





35.4.6 ”提交 过 滤器 


参数 --commit-filter 用 于 设置 提交 过 小 器。 提交 过 滤器 所 给 出 的 脚 
本 ， 在 版 本 库 重 整 过 程 的 每 次 提交 时 运行 ， 取 代 要 默认 执行 的 git 
commit-tree 命 令 。 不 过 一 般 情 况 下 会 在 脚本 中 调用 git commit-tree 命 令 。 
传递 给 脚本 的 参数 格式 为 “<TREE_ID>[ (- 





p<PARENT_COMMIT_ID>) ...]”， 提 交 日 志 以 标准 输入 的 方式 传递 给 
脚本 。 脚 本 的 输出 是 新 提交 的 提交 ID 。 作 为 扩展 ， 如 果 脚 本 输出 了 多 个 
提交 ID， 则 这 些 提 交 ID 作 为 子 提交 的 多 个 父 节点 。 


使 用 下 面 的 命令 ， 可 以 过 小 掉 空 提交 (合并 提交 除外 〉。 





$ git filter-branch --commit-filter ' 
git_commit_non_empty_tree "$@"' 








函数 git_commit non_empty_tree 是 在 脚本 git-filter-branch 中 已 经 定义 
过 的 函数 。 可 以 打开 文件 $(git --exec-path)/git-filter-branch 查 看 。 





# if you run 'git_ commit_ non_empty_tree "$@"' in a commit filter， 
# it will skip commits that leave the tree untouched, commit the other. 
git_commit_non_empty_tree() 








if test $# = 3 && test "$1" = $(git rev-parse "$3^{tree}"); then 
map "$3 中 

else 
git commit-tree "$@" 


fi 





如 果 只 想 跳 过 某 个 用 户 《 如 badboy) 的 提交 ， 而 无 论 该 提交 是 否 为 
空 ， 可 以 使 用 下 面 的 命令 





$ git filter-branch --commit-filter ' 
if [ "$GIT_AUTHOR_NAME" = "badboy" ]; 
then 
skip_commit "$@",; 
else 
git commit-tree "$@",; 
fi' HEAD 





其 中 ， 函 数 skip_commit 也 是 在 脚本 git-filter-branch 中 已 经 定义 好 了 
的 。 该 函数 的 作用 就 是 处 理 传 递 给 提交 过 滤器 脚本 的 参数 “<tree_id>-p 
parent1-p parent2...”， 形 成 “parentlparent2” 的 输出 。 参 见 Git 命 令 脚 本 $ 
(Cgit--exec-path) /git-filter-branch 中 相关 的 函数 。 





# if you run "Skip_commit "$@"' in a commit filter， it will print the (mapped) pare 
skip_commit() 


shift; 
while [ -n "$1" ]; 





35.4.7 ”里程 碑 名 字 过 滤器 


参数 --tag-name-filter 用 于 设置 里 程 碑 名 字 过 滤器 过 滤器 也 是 


种 要 用 到 的 过 沽 硕 。 上 面 介绍 的 各 个 过 滤 需 都 有 可 能 改变 提交 ID， 如 宋 
在 原 有 的 提交 ID 上 建 有 里 程 碑 ， 可 能 会 随 之 更 新 ， 但 是 会 产生 大 量 的 警 
告 日 志 ， 提 示 要 使 用 里 程 碑 过 滤器 。 里 程 碑 过 滤器 脚本 以 原始 里 程 碑 名 
称 作 为 标准 输入 ， 并 把 新 里 程 碑 名 称 作为 标准 输出 。 如 果 不 打 算 变 更 里 
程 碑 的 名 称 ， 而 只 是 希望 里 程 碑 随 提交 而 更 新 ， 可 以 在 脚本 中 使 用 cat 命 
令 。 例 如 ， 下 面 的 命令 中 同时 使 用 里 程 碑 名 字 过 滤器 和 目录 树 过 滤器 。 





$ git filter-branch --tree-filter ' 
[ -f oldfile ] && mv oldfile newfile || true 
' -- tag-name-filter 'cat' -- --all 





在 前 面 的 里 程 碑 一 章 中 曾经 提 到 过 git branch 命 令 没 有 提供 里 程 碑 重 
命名 的 功能 ， 而 使 用 里 程 碑 名 字 过 滤器 可 以 实现 里 程 碑 的 重 命名 。 下 面 
的 的 示例 会 修改 里 程 碑 的 名 字 ， 将 前 级 为 “old-prefix” 的 里 程 碑 改名 为 前 


级 为 “new-prefix” 的 里 程 碑 。 








$ git filter-branch --tag-name-filter ' 
oldtag= cat. 
newtag=${0ldtag#0ld-prefix} 
If [ "$0oldtag" != "$newtag" ]; then 
newtag="new-prefix$newtag" 
fi 
echo $newtag 





注意 签名 里 程 碑 重建 后 ， 因 为 签名 不 可 能 保持 ， 所 以 新 里 程 碑 会 丢 
弃 签 名 ， 成 为 一 个 普通 的 包含 说 明 的 里 程 碑 。 


35.4.8 子 目录 过 滤器 


参数 --subdirectory-filter 用 于 设置 子 目录 过 滤器 。 子 目录 过 滤器 可 以 
将 版 本 库 的 一 个 子 目录 提取 为 一 个 新 版 本 库 ， 并 将 该 子 目 录 作 为 版 本 库 
的 根 目录 。 例 如 从 Subversion 转 换 到 Git 版 本 库 会 因为 参数 使 用 不 当 ， 将 
原 Subversion 的 主线 转换 为 Git 版 本 库 的 一 个 目录 truank。 可 以 使 用 git 
filter-branch 命 令 的 子 目 录 过 滤器 将 trunk 提 取 为 版 本 库 的 根 。 











$ git filter-branch --subdirectory-filter trunk HEAD 





[1] 这 里 使 用 的 命令 并 非 最 优 实现 ， 后 面 会 介绍 一 个 运行 得 更 快 的 命 
令 。 
[2] http:/ /kanwei.com/code/2009/03/29/fixing-git-email.html 


[3] 参见 第 8 篇 第 41 章 “41.41 提 交 嫁 接 ” 一 节 。 


第 7 篇 ”Git 的 其 他 应 用 





Git 的 强大 和 别具一格 源 自 于 它 在 一 开始 就 没有 按照 版 本 控制 系统 
的 思路 进行 设计 。 根 据 Linus Torvalds 自 己 的 说 法 :“ 我 真 的 是 从 一 个 文 
件 系统 开发 者 所 要 面 对 的 问题 的 角度 出 发 对 Git 进 行 设计 的 〈， 内 核 
是 我 开发 的 ) ， 并 且 我 真 的 对 于 建立 一 个 传统 的 SCM 系 统 没有 一 点 兴 
趣 。 中 ”Git 最 初 仅仅 是 一 个 可 对 内 容 进行 追踪 、 可 版 本 管理 的 另类 的 文 
件 系 统 ， 在 整个 社区 的 努力 下 ，Git 终 于 成 为 一 个 成 功 的 现代 的 版 本 控 
制 系统 了 ， 而 基于 Git 的 其 他 应 用 才刚 刚 开始 。 





维基 是 使 用 易于 理解 、“ 所 见 即 所 得 ”的 文本 来 编辑 网 页 ， 实 现 基 于 
Web 的 协同 著作 工具 ， 又 称 为 “Web 的 版 本 控制 *。 在 名 为 MZ Linux 的 维 
基 网 站 上 中 可 以 看 到 一 份 用 Git 作 为 后 端 实现 的 维基 列表 (大 部 分 是 技 
术 上 的 试验 ) 。 





SpaghettiFS 项 目 中 尝试 用 Git 作 为 数据 存储 后 端 ， 提 供 了 一 个 用 户 
空间 的 文件 系统 (FUSE，Filesystem in Userspace) 。 而 另外 的 一 些 项 目 
如 gitfs 和 可 以 直接 把 Git 版 本 库 挂 载 为 文件 系统 。 








下 面 的 章节 通过 几 个 典型 的 应 用 来 介绍 Git 在 版 本 控制 领域 之 外 的 
应 用 。 让 我 们 一 起 来 领略 Git 的 神奇 吧 。 


[1] http:/ /kerneltrap.org/node/4982 


[2] http:/ /www.mzlinux.org/node/116 
[3] https://github.com/alex-morega/ SpaghettiFS 


[4] http://code.google.com/p/gitfs/ 


第 36 半 etckeeper 





Linux/Unix 的 用 户 对 /etc 目 录 是 再 熟悉 不 过 了 ， 这 个 最 重要 的 目录 中 
保存 了 大 部 分 软件 的 配置 信息 ， 借 以 实现 对 软件 的 配置 乃至 对 整个 系统 
的 启动 过 程 进行 控制 。 对 于 Windows 用 户 来 说 ， 可 以 把 /etc 目 录 视 为 
Windows 中 的 注册 表 ， 只 不 过 是 文件 化 了 ， 易 管理 了 。 





这 么 重要 的 /etc 目 录 ， 如 果 其 中 的 文件 被 错误 编辑 或 删除 ， 将 会 损 
失 惨 重 。 有 一 个 名 为 etckeeper11 的 项 目 借用 分 布 式 版 本 控制 工具 〈 如 ; 
Git、Mercurial、Bazaar、Darcs) ， 可 以 帮助 实现 /etc 目 录 的 持续 备份 。 








那么 etckeeper 是 如 何 实现 的 呢 ? 下 面 就 以 Git 作 为 etckeeper 的 后 端 为 
例 进 行 说 明 ， 其 他 的 分 布 式 版 本 控制 系统 大 同 小 异 。 


` 将 /etc 目 录 Git 化 。 于 目录 /etc/.git 中 创建 Git 库 ， 将 /etc 目 录 作 为 工 
作 区 。 


. 与 系统 的 包 管 理 器 (如 Debian/Ubuntu 的 apt、Redhat 上 的 yum 等 ) 
整合 。 一 旦 有 软件 包 安 装 或 删除 ， 就 对 /etc 目 录 下 的 改动 执行 提交 操 
人 


` 除了 能 够 记录 /etc 目 录 中 的 文件 内 容 外 ， 还 可 以 记录 文件 属性 等 


了 
元 信息 。 因 为 /etc 目 录 下 的 文件 的 权限 设置 往往 是 非常 重要 和 致命 的 。 


因为 /etc 目 录 已 经 成 了 一 个 Git 版 本 库 ， 可 以 用 Git 命 令 对 /etc 下 的 
文件 进行 操作 : 查看 历史 ， 回 退 到 历史 版 本 ， 等 等 。 


. 也 可 以 将 /etc 克 隆 到 另外 的 主机 中 ， 实 现 双 机 备份 。 


[1] http:/ /kitenet.net/~joey/code/etckeeper/ 


36.1 ”安装 etckeeper 


安装 etckeeper 非 常 简 单 ， 因 为 etckeeper 在 主流 的 Linux 发 行 版 中 都 有 
对 应 的 安装 包 。 使 用 相应 Linux 平 台 的 包 管 理 器 (apt、yum) 即 可 安 
装 。 





在 Debian/Ubuntu 上 安装 etckeeper， 如 下 : 





$ sudo aptitude install etckeeper 








安装 etckeeper 软 件 包 ， 还 会 自动 安装 一 个 分 布 式 版 本 控制 系统 工 
有 具 ， 除 非 已 经 安装 过 了 。 这 是 因为 etckeeper 需 要 使 用 一 个 分 布 式 版 本 控 
制 系统 作为 存储 管理 后 端 。 在 Debian/Ubuntu 上 会 依据 下 面 的 优先 级 进行 


安装 Git>Mercurial>Bazaar>Darcs。 





在 Debian/Ubuntu 上 ， 使 用 dpkg-s 命 令 查 看 etckeeper 的 软件 包 依 赖 ， 
就 会 看 到 这 个 优先 级 。 





$ dpkg -s etckeeper | grep "^Depends" 
Depends: git-core (>= 1:1.5.4) | git (>= 1:1.7) | mercurial | bzr (>= 1.4~) | darcs, 





36.2 ”配置 etckeeper 





配置 etckeeper 首 先 要 选择 好 一 款 分 布 式 版 本 库 控 制 工具 ， 如 Git， 然 
后 用 相应 的 版 本 控制 工具 初始 化 /etc 目 录 ， 并 做 一 次 提交 ， 具 体操 作 过 
程 如 下 。 


(1) 编辑 配置 文件 /etc/etckeeper/etckeeper.conf。 








只 要 有 下 面 一 条 配置 就 够 了 。 告 诉 etckeeper 使 用 Git 作 为 数据 管理 后 





VCS="git" 





(2) 初始 化 /etc 目 录 。 即 将 其 Git 人 化。 执行 下 面 的 命令 (需要 以 root 
用 户 的 身份 执行 ) ， 会 将 /etc 目 录 Git 化 。 整 个 过 程 可 能 会 比较 慢 ， 因 为 
要 对 /etc 下 的 文件 执行 git add， 文 件 又 太 多 ， 所 以 会 慢 一 些 。 





$ sudo etckeeper init 





(3) 执行 第 一 次 提交 。 注 意 使 用 etckeeper 命 令 而 非 Git 命 令 进行 提 


N| 
4 





$ sudo etckeeper commit "this is the first etckeeper commit,..." 





这 个 过 程 也 会 比较 慢 ， 主 要 是 因为 etckeeper 要 扫描 /etc 下 非 root 用 户 
的 文件 及 特殊 权限 的 文件 并 进行 记录 。 别 忘 了 Git 本 身 并 不 能 记录 文件 
属 主 及 文件 权限 等 信息 。 


36.3 ”使 用 etckeeper 


实际 上 由 于 etckeeper 已 经 和 系统 的 包 管 理工 具 〈 如 Debian/Ubuntu 的 
apt，Redhat 上 的 yum 等 ) 进行 了 整合 ， 所 以 etckeeper 可 以 免 维护 运行 。 
即 一 旦 有 软件 包 安 装 或 删除 ， 对 /etc 目 录 下 的 改动 会 自动 执行 提交 操 
作 。 





当然 也 可 以 随时 以 root 用 户 的 映 份 执行 下 面 的 命令 对 /etc 目 录 的 改动 
进行 手动 提交 。 





$ sudo etckeeper commit 








剩 下 的 工作 就 交 给 Git 了 。 可 以 在 ,etc 目录 中 执行 gitlog、git show 等 
操作 。 但 要 注意 以 root 用 户 的 里 份 运行 ， 因 为 /etc/.git 目 录 的 权限 不 允许 
普通 用 户 操作 。 


第 37 章 ”Gistore 





当 了 解 了 etckeeper 之 后 ， 您 可 能 会 有 如 我 一 样 的 疑问 :“ 有 没有 像 
etckeeper 一 样 的 工具 ， 但 是 能 备份 任意 的 文件 和 目录 呢 ? ” 


我 在 Google 上 搜索 类 似 的 工具 无 果 ， 终 于 决定 动手 开发 一 个 ， 因 为 
无 论 是 我 还 是 我 的 客户 ， 都 需要 一 个 更 好 用 的 备份 工具 。 这 惑 是 


Gistore。 








Gistore = Git + Store 





2010 年 1 月 ， 我 在 公司 的 博客 上 发 表 了 Gistore 0.1 版 本 的 消息 ， 参 
见 : http://blog.ossxp.com/2010/01/406/ 。 并 将 Gistore 的 源 代码 托管 在 了 


Github 上 ， 参 见 : http://github.com/ossxp-com/gistore 。 


Gistore 的 出 现 是 受到 了 etckeeper 的 启发 ， 通 过 Gistore 用 户 可 以 把 系 
统 中 任何 目录 的 数据 纳入 到 备份 中 ， 定 制 非常 简单 和 方便 。Gistore 的 特 
点 如 下 : 





` 使 用 Git 作 为 数据 后 端 。 数据 回复 和 历史 查看 等 均 使 用 熟悉 的 Git 


ES 


外 全 


[© 


` 每 次 备份 即 为 一 次 Git 提 交 ， 支 持 文 件 的 添加 /删除 /修改 / 重 命名 


` 每 次 备份 的 日 志 自 动 生成 ， 内 容 为 此 次 修改 的 摘要 信息 。 


. 支持 备份 回 滚 ， 可 以 设 定 保存 备份 历史 的 天 数 ， 让 备份 的 空间 此 
用 维持 在 一 个 相对 稳定 的 水 平 上 。 


“ 支持 跨 郑 备份。 备份 的 数据 源 可 以 来 自任 何 卷 /目录 或 文件 。 


` 备份 源 如 果 已 经 Git 化 ， 也 能 够 备份 。 例 如 /etc 目 录 因 为 etckeeper 
被 Git 化 ， 人 仍然 可 以 对 其 用 Gistore 进 行 备份 。 


. 多 机 异地 备份 非常 简单 ， 使 用 Git 克 隆 即 可 解决 。 可 以 采用 Git 协 
议 、HTIP， 或 者 更 为 安全 的 SSH 协 议 。 








说 明 : Gistore 目 前 只 能 运行 在 Linux、Mac OS X 等 类 Unix 操 作 系 统 


上 ， 因 为 在 备份 中 使 用 了 mount、umount 命 令 和 /或 FUSE 相 关 命 令 。 


37.1 ”Gistore 的 安装 


37.1.1 软件 依赖 


Gistore 运 行 时 需要 将 备份 项 逐一 挂 载 到 备份 工作 区 中 ， 因 此 需要 安 
装 相应 的 挂 载 工具 。 


. 如 果 在 Linux 上 以 普通 用 户 的 身份 运行 Gistore， 或 者 在 Mac OS 又 
上 执行 ， 则 需要 安装 bindfs 由 ， 以 便 能 够 将 备份 目录 挂 载 到 Gistore 工 作 
区 中 。 


如 果 在 Linux 上 以 管理 员 的 身份 运行 ， 则 可 以 不 安装 bindfs， 因 为 


Linux 下 的 mount--rbind 命 令 可 以 实现 备份 目录 到 Gistore 工 作 区 的 挂 载 。 
` 如 果 以 普通 用 户 的 身份 执行 ， 当 运行 挂 载 工 具 遇 到 授权 问题 时 ， 
如 果 安 装 并 且 正 确 配置 了 sudo 命 令 ， 则 会 自动 调用 sudo 命 令 执 行 。 
37.1.2 ”从 源码 安装 Gistore 
从 源 代 码 安装 和 运行 Gistore， 可 以 确保 安装 的 是 最 新 的 版 本 ， 具 体 
操作 步骤 如 下 。 


(1) 先 用 Git 从 Github 上 克隆 代码 库 。 





$ git clone git://github.com/ossxp-com/gistore.git 








(2) 可 以 直接 在 克隆 出 的 源码 中 运行 Gistore。 





$ cd gistore 
$ ./gistore --help 








(3) 也 可 以 执行 setup.py 脚 本 ， 以 Python 软件 包 特 有 的 方式 安装 。 





$ sudo python setup.py install 
$ which gistore 
/usr/local/bin/gistore 





37.1.3 ”用 easy_install 安 装 


Gistore 是 用 Python 语言 开发 的 ， 已 经 在 PYPI 上 注册 
了 : http://pypi.python.org/pypi/gistore 。 就 像 其 他 Python 软件 包 一 样 ， 可 
以 使 用 easy_install 进 行 安装 ， 具 体操 作 过 程 如 下 。 


(1) 确保 您 的 机 器 上 已 经 安装 了 setuptools | 。 





几乎 每 个 Linux 发 行 版 都 有 setuptools 软 件 包 ， 可 以 直接 用 包 管 理 器 
进行 安装 。 在 Debian/Ubuntu 上 可 以 使 用 下 面 的 命令 安装 setuptools: 





$ sudo aptitude install python-setuptools 
$ which easy_install 
/usr/bin/easy_install 





(2) 使 用 easy_install 命 令 安 装 Gistore: 





$ sudo easy_install -U gistore 





[1] http:/ /code.google.com/p/bindfs/ 


[2] http:/ /peak.telecommunity.com/DevCenter/ setuptools 


37.2 ”Gistore 的 使 用 


先 熟悉 一 下 Gistore 的 术语 。 


` 备份 库 : 通过 gistote init 命 令 创 建 用 于 数据 备份 的 数据 仓库 。 备 份 
库 包 含 的 数据 有 : 


. Git 版 本 库 相 关 的 目录 和 文件 。 如 tepo.pgit 目 录 (相当 于 .git 目 


杂 ) tienote 交 性 敬 。 
Gistotre 相 关 的 配置 。 如 .gistore/config 文 件 。 
* 备份 项 : 可 以 为 一 个 备份 库 指 定 任 意 多 的 备份 项 目 。 
` 例如 备份 /etc 目 录 ，/var/log 目 录 等 。 


. 备份 项 在 备份 库 的 .gistore/config 文 件 中 指定 ， 如 上 述 备 份 项 在 
配置 文件 中 的 写法 为 : 





[store "/etc"] 
enabled = true 
[store "/var/l1o0g"] 
enabled = true 





备份 任务 : 在 执行 Gistore 命 令 时 ， 可 以 指定 一 个 任务 或 多 个 任 


O 


任务 就 是 一 个 备份 库 的 路 径 ， 可 以 使 用 绝对 路 径 ， 也 可 以 使 用 相对 
路 径 。 如 采 不 提供 备份 任务 ， 即 不 指定 一 个 备份 库 路 径 ， 默 认 使 用 当前 
目录 。 除 了 使 用 路 径 外 ， 还 可 以 使 用 一 个 任务 别名 来 标识 备份 任务 。 


. 如 果 一 个 备份 库 在 ~/.gistore.d/tasks 目 录 ( 非 root 用 户 ) ， 或 
者 /etc/gistore/tasks 目 录 (toot 用 户 ) 下 建立 了 一 个 符号 链接 ， 则 该 符号 
链接 的 名 称 就 是 这 个 备份 库 的 任务 别名 。 


. 通过 任务 别名 的 机 制 ， 将 可 能 分 散在 磁盘 各 处 的 备份 库 汇 总 在 
一 起 ,便于 用 户 定位 备份 库 。 例 如 可 以 显示 所 有 在 ~/.gistore.d/tasks 目 录 
或 /etc/gistore/tasks 目 录 备 份 的 任务 列表 。 


37.2.1 创建 并 初始 化 备份 库 


在 使 用 Gistore 开 始 备份 之 前 ， 必 须 先 初始 化 一 个 备份 库 。 命 令 行 格 
式 如 下 : 























用 法 : gistore init [备份 任务 ] 








初始 化 备份 库 的 示例 如 下 。 


将 当前 目录 作为 备份 库 进 行 初始 化 : 





$ mkdir backup 
$ cd backup 
$ gistore init 





将 指定 的 目录 作为 备份 库 进行 初始 化 : 





$ sudo gistore init /backup/database 





当 一 个 备份 库 初始 化 完毕 后 ， 包 含 下 列 文件 和 目录 : 
- 目录 repo.git: 存储 备份 的 Git 版 本 库 。 

* 文件 .gistore/config: Gistore 的 配置 文件 。 

` 目录 logs: Gistore 运 行 的 日 志 记 录 。 


" 目录 locks: Gistore 运 行 的 文件 锁 目 录 。 


37.2.2 ”Gistore 的 配置 文件 


在 每 一 个 备份 库 的 .gistore 目 录 下 的 config 文 件 是 该 备份 库 的 配置 文 
件 ， 用 于 记录 Gistore 的 备份 项 内 容 ， 以 及 备份 回 深 设置 等 。 


例如 下 面 的 配置 内 容 《〈 为 描述 方便 添加 了 行 号 ) : 





1 # Global config for all sections 
2 [main] 

3 backend = git 

4 backuphistory = 200 

5 backupcopies = 5 

6 rootonly = no 

7 version = 2 


9 [default] 


10 keepemptydir = no 
11 keepperm = no 
12 


13 # Manage your backup list using: gistore add, gistore rm commands. 
14 [store "/opt/mailman/archives"] 

15 enabled = true 

16 [store "/opt/mailman/conf"] 

17 enabled = true 

18 [store "/opt/moin/conf"] 

19 enabled = true 





如 何 理 解 这 个 配置 文件 呢 ? 
` 第 2 行 到 第 7 行 的 [main] 小 节 用 于 Gistore 的 全 局 设置 。 


第 3 行 设置 了 Gistore 使 用 的 SCM 后 端 为 Git， 这 是 目前 唯一 可 用 的 


设置 。 


` 第 4 行 设置 了 Gistore 的 每 一 个 历史 分 支 保存 的 最 多 的 提交 数目 ， 


默认 为 200 个 提交 。 当 超过 这 个 提交 数目 时 ， 进 行 备份 回 深 。 


. 第 5 行 设置 了 Gistore 保 存 的 历史 分 支 数量 ， 默 认为 5 个 历史 分 支 。 
每 当 备份 回 滚 时 ， 会 将 备份 主线 保存 到 名 为 gistore/1 的 历史 分 支 中 。 


* 第 6 行 设 置 非 tfoot only 模式 。 如 果 开 局 foot only 模式 ， 则 只 有 toot 
用 户 能 够 执行 此 备份 库 的 备份 。 


.第 7 行 设置 了 Gistote 备 份 库 的 版 本 。 


" 第 9 行 开始 的 [default] 小 节 设 置 后 面 的 备份 项 小 节 的 默认 设置 。 在 
后 面 的 [stote..] 小 节 可 以 履 盖 此 默认 设置 。 


` 第 10 行 设置 是 否 保留 空 目 录 。 暂 未 实现 。 
- 第 11 行 设置 是 否 保持 文件 属 主 和 权限 。 暂 未 实现 。 


第 14 行 到 第 19 行 是 备份 项 小 节 ， 小 节 名 称 以 store 开 始 ， 后 面 的 部 
分 即 为 备份 项 的 路 径 。 例 如 [store/opt/mailman/archives] 的 含义 是 : 要 


对 /opt/mailman/archives 目 录 进 行 备份 。 
37.2.3 ”Gistore 的 备份 项 管理 
请 不 要 直接 编辑 .gistore/config 文 件 ， 以 免 因为 格式 错误 导致 Gistore 


无 法 运行 。 可 以 通过 git config 命 令 对 该 文件 进行 操作 ， 因 为 实际 上 这 个 
文件 就 是 用 git config 命 令 创 建 的 。 








$ git config -f .gistore/config store./some/dir.enabled false 
$ git config -f .gistore/config -1 





Gistore 提 供 了 几 个 子 命 令 ， 对 备份 项 进行 管理 。 


1. 添 加 备份 项 


进入 备份 库 目录 ， 执 行 下 面 的 命令 ， 添 加 备份 项 /some/dir。 注 意 备 
份 项 要 使 用 全 路 径 ， 即 要 以 “开始 。 





$ gistore add /some/dir 





2. 删 除 备 份 项 


进入 备份 库 目录 ， 执 行 下 面 的 命令 ， 则 删除 备份 项 /some/dir。 第 一 
次 执行 该 命令 停 用 该 备份 项 的 备份 ， 即 将 store./some/dir.enabled 配 置 变 


量 设置 为 false。 当 第 二 次 执行 该 删除 命令 ， 则 彻 哲 删除 该 备份 项 。 





$ gistore rm /some/dir 





3. 查 看 备份 项 


进入 备份 库 目 录 ， 执 行 gistore status 命 令 ， 显 示 备 份 库 的 设置 及 备 
份 项 列表 。 





$ gistore status 
Task name : system 
Directory : /data/backup/gistore/system 
Backend : git 
Backup capability : 200 commits * 5 copies 
Backup list : 

/backup/databases (--) 
/backup/ldap (--) 
/data/backup/gistore/system/ .gistore (--) 
/etc (AD) 
/opt/cosign/conf (--) 
/opt/cosign/factor (--) 
/opt/cosign/lib (--) 
/opt/gosa/conf (--) 
/opt/ossxp/conf (--) 
/opt/ossxp/ssl (--) 





从 备份 库 的 状态 输出 可 以 看 到 : 


` 备份 库 有 一 个 任务 别名 为 system。 


` 备份 库 的 路 径 是 /data/backup/gistore/system。 


. 备份 的 容量 是 200*5， 如 果 按 每 天 备份 一 次 来 计算 ， 总 共 可 以 保 
存 1000 天 ， 差 不 多 3 年 的 数据 备份 。 


* 在 备份 项 列表 ， 可 以 看 到 多 达 10 个 备份 项 。 


每 个 备份 项 后 面 的 括号 代表 其 备份 选项 ， 其 中 /etc 的 备份 选项 为 
AD。A 代 表 记 录 并 保持 授权 ，DD 的 含义 是 保持 空 目录 。 


37.2.4 执行 备份 任务 


执行 备份 任务 非常 简单 : 


` 进入 到 备份 库 根 目录 下 ， 执 行 : 





$ sudo gistore commit -m "The reason for backup" 





. 或 者 在 命令 行 上 指定 备份 库 的 路 径 : 





$ sudo gistore ci /backup/database 





说 明 : ci 为 commit 命 令 的 简称 。 


37.2.5 “查看 备份 日 志 


备份 库 中 的 repo.git 束 是 备份 数据 所 在 的 Git 库 ， 这 个 Git 库 是 一 个 不 


市 工作 区 的 裸 库 。 可 以 对 其 执行 git log 命 令 来 查看 备份 日 志 。 


因为 并 非 采 用 通常 的 .git 作 为 版 本 库 名 称 ， 而 且 不 市 工作 区 ， 需 要 
通过 --git-dir 参 数 指定 版 本 库 的 位 置 ， 如 下 : 





$ git --git-dir=repo.git log 





Gistore 提 供 了 一 个 log 子 命令 ， 能 更 方便 地 显示 备份 日 志 。 该 子 命 
令 实 际 是 对 上 面 的 Git 命 令 的 封 效 ， 因 此 可 以 向 其 传递 任何 git log 命 令 可 
以 理解 的 参数 。 如 : 





$ gistore 10g --pretty=oneline 





下 面 是 我 公司 内 的 服务 器 每 日 备份 的 日 志 片 断 : 





commit 9d1i6b5668c1la09f6fa0b0142c6d34f3cbb33072f 
Author: Jiang Xin <jiangxin@ossxp.com> 
Date: Thu Aug 5 04:00:23 2010 +0800 
Changes summary: total= 423, A: 407, D: 1, M: 15 

A => etc/gistore/tasks/Makefile, 
opt/cosign/1ib/share/locale/cosign.pot, 
opt/cosign/lib/templates-local.old/expired error.html, 
opt/cosign/1lib/templates-local.old3/error.html, 
opt/cosign/lib/templates/inc/en/0020_scm.html, ...402 more... 

D => etc/gistore/tasks/default 

M => .gistore/config, etc/gistore/tasks/gosa, 
etc/gistore/tasks/testlink, etc/group, etc/gshadow-, ...10 more... 
commit 01b6bce2e4ee2f8cda57ceb3c4dbodb9eb9gbbed 
Author: Jiang Xin <jiangxin@ossxp.com> 
Date: Wed Aug 4 04:01:09 2010 +0800 

Changes summary: total= 8, A: 7, M: 1 

A => backup/databases/blog bj/blog_bj.sql, 
backup/databases/ossxp/mysql.sql, backup/databases/redmine/redmine.sql, 
backup/databases/testlink/testlink-1.8.sql, 
backup/databases/testlink/testlink.sql, ...2 more... 

M => .gistore/config 
commit 15ef2e88f33dfa7dfbo4ecbcdb9e6b2a7c4e6b00 
Author: Jiang Xin <jiangxin@ossxp.com> 


Date: Tue Aug 3 16:59:12 2010 +0800 
Changes summary: total= 2665, A: 2665 
A => .gistore/config, etc/apache2/sites-available/gems, etc/group-, 
etc/pam.d/dovecot, etc/ssl/certs/0481cb65.0, ...2660 more... 





从 上 面 的 日 志 可 以 看 出 : 


- 备份 发 生 在 晚上 4 点 钟 左 右 。 这 是 因为 备份 是 在 晚上 自动 执行 
的 。 


:ID 为 “15ef2e8 的 提交 是 一 次 手动 提交 。 从 提交 说 明 中 可 以 看 到 


添加 了 2665 个 文件 。 


. 最 新 的 备份 JD 为 “9d16b56”， 其 中 既 有 文件 添加 (A) ， 又 有 文 
件 删除 (D) ， 还 有 文件 变更 (M) ， 会 随机 各 选择 5 个 文件 出 现在 提交 
癌症 


如 宁 想 得 看 详细 的 文件 变更 列表 ， 使 用 下 面 的 命令 : 





$ gistore 1og -1 --stat 9d16b56 
commit 9d1i6b5668c1la09f6fa0b0142c6d34f3cbb33072f 
Author: Jiang Xin <jiangxin@ossxp.com> 
Date: Thu Aug 5 04:00:23 2010 +0800 
Changes summary: total= 423, A: 407, D: 1, M: 15 

A => etc/gistore/tasks/Makefile, 
opt/cosign/1ib/share/locale/cosign.pot, 
opt/cosign/l1ib/templates-local.old/expired error.html, opt/cosign/l1ib/templ 

D => etc/gistore/tasks/default 

M => .gistore/config, etc/gistore/tasks/gosa, 


etc/gistore/tasks/testlink, etc/group, etc/gshadow-, ...10 more... 
.gistore/config | 4+ 
backup/databases/redmine/redmine.sql | 44 +- 
etc/apache2/include/redmine/redmine.conf | 40 +- 
etc/gistore/tasks/Makefile | 了, 广 
etc/gistore/tasks/default | 1 - 
etc/gistore/tasks/gosa | 2 +- 


opt/gosa/conf/sieve-spam.txt | 6 + 


opt/gosa/conf/sieve-vacation.txt | 4 
opt/ossxp/conf/cron.d/ossxp-backup 8 


十 
423 files changed, 30045 insertions(+), 51 deletions(-) 


在 备份 库 的 logs 目 录 下 ， 还 有 一 个 备份 过 程 的 日 志文 件 
logs/gitstore.log。 记 录 了 每 次 备份 的 诊断 信息 ， 主 要 用 于 调试 Gistore。 





37.2.6 ”查看 及 恢复 备份 数据 

所 有 的 备份 数据 ， 实 际 上 都 在 repo.git 目 录 指 向 的 Git 库 中 维护 。 如 
何 获 取 这 些 备份 数据 呢 ? 

1. 克 隆 方式 检 出 

执行 下 面 的 命令 ， 克 隆 裸 版 本 库 repo.git: 


$ git clone repo.git data 


进入 data 目 录 ， 就 可 以 以 Git 的 方式 查看 历史 数据 ， 以 及 恢复 历史 数 
据 。 当 然 恢复 出 来 的 历史 数据 还 要 拷贝 到 原始 位 置 才 能 真正 实现 数据 的 
恢复 。 








2. 分 离 的 版 本 库 和 工作 区 方式 检 出 





还 有 一 个 稍微 复杂 点 的 方法 ， 惑 是 既然 版 本 库 已 经 在 repo.git 中 了 ， 
可 以 直接 利用 它 ， 避 免 克 隆 导 臻 空间 上 的 浪费 ， 尤 其 是 当 备 份 库 异常 庞 


大 的 时 候 ， 有 具体 操作 过 程 如 下 。 


(1) 创建 一 个 工作 目录 ， 如 export。 





$ mkdir export 








(2) 设置 环境 变量 ， 制 定 版 本 库 和 工作 区 的 位 置 。 注 意 使 用 绝对 








$ export GIT_DIR=/path/to/repo.git 
$ export GIT_ WORK_TREE=/path/to/export 





(3) 然后 就 可 以 进入 export 目 录 ， 执 行 Git 操 作 了 。 





$ cd /path/to/export 
$ git status 
$ git checkout ， 








37.2.7 备份 回 深 及 设置 


我 在 开发 Gistore 时 ， 最 麻烦 的 束 是 备份 历史 的 管理 。 如 果 不 对 备份 
历史 进行 回 深 ， 必 然 会 导致 提交 越 来 越 多 ， 备 份 空间 占用 越 来 越 大 ， 直 
至 磁盘 空间 占 满 。 





最 早 的 想法 是 使 用 git rebase 命 令 ， 即 将 准备 丢弃 的 早期 备份 历史 压 
纵 为 一 个 提交 ， 然 后 后 面 的 提交 再 变 基 到 压缩 后 的 提交 之 上 ， 这 样 就 实 


现 了 对 历史 提交 的 丢弃 。 但 是 这 样 的 操作 既 费 时 ， 双 复杂。 忽然 有 一 天 
灵机 一 动 ， 为 什么 不 用 分 支 来 保留 回 深 的 数据 ? 至 于 备份 主线 (master 
分 文 ) 则 从 一 个 新 的 提交 开始 重建 。 





回 滚 后 master 分 文 如 何 从 一 个 新 提交 开始 呢 ? 较 早 的 实现 是 直接 重 
置 到 一 个 空 提交 (gistore/0) 上 ， 但 是 这 样 会 导致 接 下 来 的 备份 非常 耗 
时 。 最 新 的 实现 是 使 用 git hash-object 命 令 ， 直 接 对 回 深 前 master 分 支 的 


最 新 提交 进行 改造 ， 创 造 出 一 个 没有 父 提交 的 新 提交。 








备份 回 滚 的 具体 实现 过 程 是 : 
(1) 每 次 备份 ， 都 提交 在 Git 库 的 分 文 master 上 。 


(2) 当 Git 库 的 master 分 文 的 提交 数量 达到 规定 的 六 值 〈 默 认 200) 
时 ， 则 从 master 分 支 建 立新 的 分 支 : gistore/1。 如 果 已 有 分 支 gistore/1 则 


建立 分 支 gistore/2， 依 次 类 推 。 





(3) 然后 master 分 支 重 置 到 一 个 用 git hash-object 命 令 基于 当前 最 新 


提交 建立 的 一 个 新 提交 〈 没 有 父 提 交 ) 。 


(4) 如 果 保 存 备份 历史 的 分 文 数量 达到 预先 设 定 的 国 值 〈 默 认 5 个 
分 文 ) ， 分 支 依次 回 滚 。 


" 用 分 支 gistore/2 重 置 分 支 gistore/1， 用 分 支 gistore/3 重 置 分 支 
8gistofe/2， 依 次 类 推 。 即 保存 最 早 备 份 历史 的 分 支 gistote/1 被 丢弃 。 


. 基于 分 支 mastet 建 立 分 支 gistote/5。 





《5) 当 分 支 重 置 及 回 滚 发 生 后 ， 对 备份 库 的 远程 数据 同步 不 会 有 
什么 影响 ， 传 输 的 数据 量 也 仪 是 新 增 备 份 和 上 一 次 备份 的 差异 。 


虽然 备份 历史 由 于 master 分 支 的 重 置 被 分 割 为 多 个 独立 的 片段 ， 但 
是 因为 使 用 了 Git 提 交 嫁 接 帆 的 功能 ， 执 行 gistore log 可 以 看 到 master 分 
支 及 其 他 形 如 gistore/N 分 支 的 所 有 提交 日 志 。 奥 秘 就 在 
repo.git/info/grafts 文 件 。 





37.2.8 注册 备份 任务 别名 





因为 Gistore 可 以 在 任何 目录 下 创建 备份 任务 ， 用 户 很 难 确定 当前 到 
底 存 在 多 少 个 备份 库 ， 因 此 需要 提供 一 个 机 制 ， 让 用 户 能 够 对 备份 库 进 
行 统一 管理 。 还 有 一 个 原因 ， 残 是 在 使 用 Gistore 时 寿 使 用 长 长 的 备份 库 
路 径 作 参数 会 显得 非常 茶 拙 。 任 务 别名 就 是 用 来 解决 这 些 问题 的 。 





任务 别名 实际 上 就 是 备份 库 在 用 户主 目录 下 的 ~/.gistore.d/tasks 目 录 
( 非 管理 员 )〉 或 /etc/gistore/tasks 目 录 〈 管 理 员 ) 下 创建 的 符号 连接 。 例 
如 : 管理 员 在 /etc/gistore/tasks 目 录 下 创建 备份 库 的 符号 链接 : 








$ sudo ln -s /home/jiangxin/Desktop/mybackup /etc/gistore/tasks/jx 
$ sudo ln -s /backup/database /etc/gistore/tasks/db 





然后 就 可 以 用 别名 来 访问 对 应 的 备份 库 ， 简 化 备份 命令 : 





$ sudo gistore commit jx 
$ sudo gistore commit db 





查看 一 份 完整 的 备份 列表 也 非常 简单 ， 执 行 gistore list 命 令 即 可 。 





$ sudo gistore list 
db : /backup/database 
jx : /home/jiangxin/Desktop/mybackup 








当 gistore list 命 令 后 面 指定 茶 个 任务 列表 时 ， 相 当 于 执行 gistore 


status 命 令 ， 碍 看 备份 状态 信息 : 





$ sudo gistore list db 





可 以 用 一 条 命令 对 所 有 的 任务 别名 执行 备份 : 





$ sudo gistore commit-all 





37.2.9 ”自动 备份 : crontab 


在 /etc/cron.d/ 目 录 下 创建 一 个 文件 ， 如 /etc/cron.d/gistore， 包 含 如 下 





## gistore backup 
0 4 * 四 root /usr/bin/gistore commit-all -VVVV 





这 样 每 天 凌晨 4 点 ， 就 会 以 root 用 户 的 身份 执行 gistore commit-all 命 
令 。 参 数 -vvvv 的 含义 是 提供 更 多 的 诊断 输出 。 


NS 


将 Gistore 备 份 库 在 /etc/gistore/tasks 目 录 下 创建 一 个 符号 链接 ， 就 可 
以 每 天 自动 启动 相应 Gistore 备 份 库 的 备份 。 








[1] 第 8 篇 第 41 章 “41.4.h1 提 交 嫁 接 ” 小 节 。 


37.3 ”Gistore 双 机 备份 


Gistore 备 份 库 的 主体 就 是 repo.git， 即 一 个 Git 库 。 可 以 架设 一 个 Git 
服务 器 ， 远 程 主机 通过 克隆 该 Git 服 务 器 的 备份 库 实现 双 机 备份 甚至 是 
异地 备份 。 而 且 最 酪 的 是 ， 整 个 数据 同步 的 过 程 是 可 视 的 、 快 速 的 和 无 
痛 的 ， 感 谢 伟 大 而 又 神奇 的 Git。 





最 好 使 用 公 钥 认证 的 、 基 于 SSH 的 Git 服 务 器 架设 ， 一 来 可 以 实现 无 
口令 的 数据 同步 ， 二 来 增加 了 安全 性 ， 因 为 备份 数据 中 可 能 包含 敏感 数 
据 。 








还 有 可 以 直接 利用 现成 的 /etc/gistore/tasks 目 录 作 为 版 本 库 的 根 。 当 
然 还 需要 在 架设 的 Git 服 务 器 上 ， 使 用 一 个 地 址 变换 的 小 窍门 。Gitosis 服 
务 占 软件 的 地 址 变换 魔法 正好 可 以 帮助 实现 ， 请 参见 第 5 篇 第 31 
章 “31.5 ” 轻 量 级 管理 的 Git 服 务 ”。 








第 38 章 ”补丁 中 的 二 进 制 文件 


有 的 时 候 ， 需 要 将 代码 的 改动 以 补丁 文件 的 方式 进行 传递 ， 最 终 合 
并 至 版 本 库 。 例 如 直接 在 软件 部 车 目 录 内 进行 改动 ， 再 将 改动 传送 到 开 
发 平台 。 或 者 是 因为 在 某 个 开源 软件 的 官方 版 本 库 中 没有 提交 权限 ， 需 
要 将 目 己 的 改动 以 补丁 文件 的 方式 提供 给 官方 。 








关于 补丁 文件 的 格式 ， 补 丁 的 生成 和 应 用 在 第 3 篇 的 “第 20 章 补丁 文 
件 交 互 ? 当 中 已 经 进行 了 详细 介绍 ， 使 用 的 是 git format-patch 和 git am 命 
令 ， 但 这 两 个 命令 仅 对 Git 库 有 效 。 如 果 没 有 使 用 Git 对 改动 进行 版 本 控 
制 ， 而 仅仅 是 两 个 目录 : 一 个 改动 前 的 目录 和 一 个 改动 后 的 目录 ， 大 部 
分 人 会 选择 使 用 GNU 的 diff 命 令 及 patch 命 令 实 现 补丁 文件 的 生成 和 补丁 
的 应 用 。 








但 是 GNU 的 diff 命 令 〈 包 括 很 多 版 本 控制 系统 ， 如 SVN 的 svn diff 命 
令 ) 生成 的 差异 输出 有 一 个 非常 大 的 不 足 或 者 说 漏洞 ， 就 是 差异 输出 不 
支持 二 进 制 文件 。 如 果 生 成 了 新 的 二 进 制 文件 〈 如 图 片 ) ， 或 者 二 进 制 
文件 发 生 了 变化 ， 在 差异 输出 中 无 法 体现 ， 当 这 样 的 差异 文件 被 导出 ， 
应 用 到 代码 树 中 ， 会 发 现 二 进 制 文件 或 二 进 制 文件 的 改动 丢失 了 ! 








Git 突 破 了 传统 差异 格式 的 限制 ， 通 过 引入 新 的 差异 格式 ， 实 现 了 
对 二 进 制 文件 的 文 持 。 并 且 更 为 神奇 的 是 ， 不 必 使 用 Git 版 本 库 对 数据 








进行 维护 ， 可 以 直接 对 两 个 普通 目录 进行 Git 方 式 的 差 寞 比较 和 输出 。 


38.1 Git 版 本 库 中 二 进 制 文件 变更 的 支持 


1. 创 建 支持 二 进 制 文件 的 补丁 


对 Git 工 作 区 的 修改 进行 差异 比较 (git diff--binary) ， 可 以 输出 二 
进 制 的 补丁 文件 。 包 含 二 进 制 文件 兰 异 的 补丁 文件 可 以 通过 git apply 命 
令 应 用 到 版 本 库 中 。 可 以 通过 下 面 的 示例 看 看 Git 的 补丁 文件 是 如 何 对 
二 进 制 文件 提供 支持 的 ， 具 体操 作 过 程 如 下 。 





(1) 首先 建立 一 个 空 的 Git 版 本 库 。 





$ mkdir /tmp/test 

$ cd /tmp/test 

$ git init 

initialized empty Git repository in /tmp/test/.git/ 
$ git commit --allow-empty -m initialized 

[master (root-commit) 2ca650c] initialized 





(2) 然后 在 工作 区 创建 一 个 文本 文件 readme.txt， 以 及 一 个 二 进 制 
文件 binary.data。 二 进 制 的 数据 是 从 系统 中 的 二 进 制 文件 bin/ls 读 取 而 来 
的 ， 当 然 可 以 用 任何 其 他 的 二 进 制 文件 代 奉 。 





$ echo hello > readme .txt 

$ dd if=/bin/ls of=binary.data count=1 bs=32 
记录 了 1+9 的 读 入 

记录 了 1+Q 的 写 出 
32 字 节 (32 B) 已 复制 ，9.0001062 秒 ，301 kB/ 秒 











注 : 拷贝 /bim/ls 可 执行 文件 二进制 的 前 32 个 字 节 作为 binary.data 


文件 。 





(3) 如 果 执 行 git diff--cached 则 看 到 的 是 未 扩展 的 过 异 格式 。 





$ git add . 

$ git diff --cached 

diff --git a/binary.data b/binary.data 
new file mode 100644 

index 0000000. .dc2e37f 

Binary files /dev/null and b/binary.data differ 
diff --git a/readme.txt b/readme.txt 
new file mode 100644 

index 0000000. .ce01362 

--- /dev/null 

+++ b/readme.txt 

@@ -0, 90 +1 @@ 

+hello 





可 以 看 到 对 于 binary.data， 此 差异 文件 没有 给 出 差 寞 内 容 ， 而 只 是 


一 行 “Binary files...and...differ”。 


(4) 再 执行 git diff--cached--binary 试 试看 ， 即 增加 了 参数 --binary。 





$ git diff --cached --binary 

diff --git a/binary.data b/binary.data 
new file mode 100644 

index 
O0000000000000000000000000000000000000000. .dc2e37f81e0fa88308bec48cd5195b6 
542e61a20 

GIT binary patch 

literal 32 
bcmb<-^>JfjwMqH=CI&kOSHCROOW1UNGBE; C 
literal 0 

HcmV?d00001 

diff --git a/readme.txt b/readme.txt 
new file mode 100644 

index 0000000, .ce01362 

--- /dev/null 

+++ b/readme.txt 

@@ -0, 0 +1 @@ 

+hello 





看 到 了 吗 ， 此 差异 文件 给 出 了 二 进 制 文 件 binary.data 差 异 的 内 容 ， 


并 且 差 异 内 容 经 过 base85 上 文本 化 了 。 


(5) 提交 后 ， 用 新 的 内 容 窗 新 binary.data 文 件 。 





$ git commit -m "new text file and binary file" 
[master 7ab2d01] new text file and binary file 
2 files changed, 1 insertions(+), 0 deletions(-) 
create mode 100644 binary.data 
create mode 100644 readme.txt 
$ dd if=/bin/ls of=binary.data count=1 bs=64 
记录 了 1+0 的 读 入 
记录 了 1+0 的 写 出 
64 字 节 (64 B) 已 复制 ，9.00011264 秒 ，568 kB/ 秒 
$ git commit -a -m "change binary.data." 
[master a7r9bcbe] change binary.data. 
1 files changed, 0 insertions(+), 0 deletions(-) 











(6) 再 来 看 看 更 改 后 的 二 进 制 文件 的 新 差异 格式 。 





$ git Show HEAD --binary 
commit a79bcbe50c1d278db9c9db8e42d9bc5bc72bf031 
Author: Jiang Xin <jiangxin@ossxp.com> 
Date: Sun Oct 10 19:22:30 2010 +0800 

change binary ,data， 
diff --git a/binary.data b/binary.data 
index 
dc2e37f81e0fa88308bec48cd5195b6542e61a20. .bf948689934caf2d874ff8168cb716f 
bc2a127c3 100644 
GIT binary patch 
delta 37 
hcmY#zn4qBGzyJX+<}pH93=9qo77QFfQiegAOQRUZd1MdI; 
delta 4 
LcmZ=zn4kav0O;B;E 





XN 


(7) 更 简单 的 ， 使 用 git format-patch 命 令 ， 直 接 将 最 近 的 两 次 提交 
导出 为 补丁 文件 。 





$ git format-patch HEADAA 
0001-new-text-file-and-binary-file.patch 
0002-change-binary.data.patch 





坚 无 疑问 ， 这 两 个 补丁 文件 都 包含 了 对 二 进 制 文件 的 文 持 。 





$ cat 0002-change-binary.data.patch 

From a79bcbe50c1d278db9c9db8e42d9bc5bc72bf031 Mon Sep 17 00:00:00 2001 
From: Jiang Xin <jiangxin@ossxp.com> 

Date: Sun, 10 Oct 2010 19:22:30 +0800 

Subject: [PATCH 2/2] change binary.data. 


binary.data | Bin 32 -> 64 bytes 

1 files changed, 0 insertions(+), 0 deletions(-) 
diff --git a/binary.data b/binary.data 

index 

dc2e37f81e0fa88308bec48cd5195b6542e61a20. .bf948689934caf2d874ff8168cb716f 
bc2a127c3 100644 
GIT binary patch 
delta 37 
hcmY#zn4qBGzyJX+<}pH93=9q0o77QFfQiegAORUZd1MdI; 
delta 4 

LcmZ=zn4kav0O;B;E 


771 








2. 应 用 包含 二 进 制 文件 差异 的 补丁 





应 用 包含 二 进 制 文件 差异 的 补丁 ， 不 能 使 用 GNU patch 命 令 ， 因 为 
前 面 曾 经 说 过 GNU 的 diff 和 patch 不 文 持 二 进 制 文件 的 补丁 ， 当 然 也 不 文 
持 Git 的 新 的 补丁 格式 。 将 Git 格 式 的 补丁 应 用 到 代码 树 ， 只 能 使 用 Git 命 


令 ， 即 git apply 命 令 。 





接着 前 面 的 例子 。 首 先 将 版 本 库 重 置 到 最 近 两 次 提交 之 前 的 状态 ， 
即 丢 弃 最 近 的 两 次 提交 ， 然 后 将 两 个 补丁 都 合并 到 代码 树 中 ， 具 体操 作 
步骤 如 下 。 


(1) 重 置 版 本 库 到 两 次 提交 之 前 的 状态 。 





$ git reset --hard HEADAA 
HEAD is now at 2ca650c initialized 


$ 1s 
0001-new-text-file-and-binary-file.patch 0002-change-binary.data.patch 





(2) 使 用 git apply 应 用 补丁 。 





$ git apply 0001-new-text-file-and-binary-file,.patch 
0002-change-binary.data.patch 





(3) 可 以 看 到 64 字 节 长 度 的 binary.data 又 回来 了 。 





$ 1s -1 

总 用 量 16 

-rw-r--r-- 1 jiangxin jiangxin 754 10 月 10 19:28 
0001-new-text-file-and-binary-file.patch 

-rw-r--r-- 1 jiangxin jiangxin 524 10 月 10 19:28 
0002-change-binary.data.patch 

-rw-r--r-- 1 jiangxin jiangxin 64 10 月 10 19:34 binary.data 
-rw-r--r-- 1 jiangxin jiangxin 6 10 月 10 19:34 readme ,txt 








(4) 最 后 不 要 二 了 提 区 。 





$ git add readme.txt binary.data 
$ git commit -m "new text file and binary file from patch files." 
[master 7c1389f] new text file and binary file from patch files. 
2 files changed, 1 insertions(+), 0 deletions(-) 
create mode 100644 binary.data 
create mode 100644 readme.txt 





Git 对 补丁 文件 的 扩展 ， 实 际 上 不 只 是 增加 了 三 进 制 文件 的 支持 ， 
还 提供 了 对 文件 重 命 名 (rename from 和 rename to 指令 ) 、 文 件 找 贝 
(copy from 和 copy to 指令 ) 、 文 件 删 除 (deleted file 指 令 ) 及 文件 权限 


(new file mode 和 new mode 指 令 ) 的 支持 。 





[1 Git 源 代码 diff.c 的 emit_binaty_dqdiff_ body 函数 。 


38.2 ”对 非 Git 版 本 库 中 二 进 制 文件 变更 的 支持 


不 在 Git 版 本 库 中 的 文件 和 目录 可 以 比较 生成 Git 格 式 的 补丁 文件 
吗 ， 以 及 可 以 执行 应 用 补丁 的 操作 吗 ? 


是 的 ，Git 的 diff 命 令 和 apply 命 令 文 持 对 非 Git 版 本 库 /工作 区 进行 的 
操作 。 但 是 1.7.3 以 前 版 本 的 Git 的 git apply 命 令 有 一 个 Bug， 这 个 Bug 导 致 
目前 的 git apply 命 令 只 能 应 用 patch level (补丁 文件 前 级 级 别 ) 为 1 的 补 
丁 。 我 已 经 将 改正 这 个 Bug 的 补丁 文件 提交 到 了 Git 开 发 列表 中 中， 但 有 
其 他 人 先 于 我 修正 了 这 个 Bug。 不 管 最 终 的 修正 方法 如 何 ， 在 新 版 本 的 


Git 中 ， 这 个 问题 应 该 已 经 解决 。 


下 面 的 示例 将 演示 如 何 对 非 Git 版 本 库 使 用 git diff 和 git patch 命 令 。 
首先 准备 两 个 目录 ， 一 个 为 hello-1.0 目 录 ， 在 其 中 创建 一 个 文本 文件 及 
一 个 二 进 制 文件 。 


$ mkdir hello-1.0 

$ echo hello > hello-1.0/readme.txt 

$ dd if=/bin/ls of=hello-1.0/binary.dat count=1 bs=32 
记录 了 1+9 的 读 入 

记录 了 1+0 的 写 出 
32 字 节 (32 B) 已 复制 ，9.0091026 秒 ，312 kB/ 秒 








另外 一 个 hello-2.0 目 录 ， 其 中 的 文本 文件 和 二 进 制 文件 都 有 所 更 
改 。 





$ mkdir hello-2.0 

$ printf "hello\nworld\n" > hello-2.0/readme.txt 

$ dd if=/bin/ls of=hello-2.0/binary.dat count=1 bs=64 
记录 了 1+0 的 读 入 

记录 了 1+0 的 写 出 
64 字 节 (64 B) 已 复制 ，0.0001022 秒 ，626 kB/ 秒 











然后 执行 git diff 命 令 。 命 令 中 的 --no-index 参 数 对 于 不 在 版 本 库 中 的 
目录 /文件 进行 比较 时 可 以 省 略 。 其 中 还 用 了 --no-prefix 参 数 ， 这 样 就 可 
以 生成 前 级 级 别 (patch level ) 为 1 的 补丁 文件 。 





$ git diff --no-index --binary --no-prefix \ 
hello-1.0 hello-2.0 > patch.txt 
$ cat patch .txt 
diff --git hello-1.0/binary.dat hello-2.0/binary.dat 
index 
dc2e37f81e0fa88308bec48cd5195b6542e61a20. .bf948689934caf2d874ff8168cb716fbc2a 
127c3 100644 
GIT binary patch 
delta 37 
hcmY#zn4qBGzyJX+<}pH93=9q0o77QFfQiegAORUZd1MdI; 
delta 4 
LcmZ=zn4kavO;B;E 
diff --git hello-1.0/readme.txt hello-2.0/readme.txt 
index ce01362. .94954ab 100644 
--- hello-1.0/readme.txt 
+++ hello-2.0/readme.txt 
@@ -1 +1, 2 @@ 
hello 
+world 





进入 到 hello-1.0 目 录 ， 执 行 git apply 应 用 补丁 ， 即 使 hello-1.0 不 是 一 
个 Git 库 。 





$ cd hello-1.0 
$ git apply ../patch.txt 





会 惊喜 地 发 现 hello-1.0 应 用 补丁 后 ， 已 经 变 得 和 hello-2.0 一 样 了 。 





$ git diff --stat . ../hello-2.0 





命令 git apply 也 支持 反 向 应 用 补丁 。 反 向 应 用 补丁 后 ，hello-1.0 中 的 
文件 被 还 原 ， 和 hello-2.0 比 较 又 可 以 看 到 差异 了 。 





$ git apply -R ../patch.txt 

$ git diff --stat . ../hello-2.0 
{. => ../hello-2.0}/binary.dat | Bin 32 -> 64 bytes 
{. => ../hello-2.0}/readme.txt | 工 十 
2 files changed， 1 insertions(+)， 0 deletions(-) 





[1] http:/ /marc.info/?l=git&m=129058163119515&w=2 


38.3 ”其 他 工具 对 Git 扩 展 补丁 文件 的 支持 





Git 对 二 进 制 提供 支持 的 扩展 的 补丁 文件 格式 ， 已 经 成 为 补丁 文件 
格式 的 新 标准 ， 被 其 他 一 些 应 用 软件 所 接受 。 例 如 Mercual/Hg 就 提供 了 
对 Git 扩 展 补 丁 格式 的 文 持 。 


为 hg diff 命 令 增加 --git 参 数 ， 实 现 Git 扩 展 diff 格 式 的 输出 。 





$ hg diff --git 





Hg 的 MQ 插件 提供 了 对 Git 补 丁 的 支持 。 





$ cat .hg/patches/1.diff 

# HG changeset patch 

# User Jiang Xin <worldhello.net AT gmail DOT com> 
# Date 1286711219 -28800 

# Node ID ba66b7bca4baec41a7d29c5cae6bea6d868e2c4b 
# Parent 0b44094c755e181446c65c16a8b602034e65efd7 


diff --git a/binary.data b/binary.data 

new file mode 100644 

index 

QQ000000000000000000000000000000000000000. .dc2e37f81e0fa88308bec48cd5195b6542e 
61a20 

GIT binary patch 

literal 32 

bc$}+u^>JfjWwMqH=CI&kOSHCROON7&gGBE; C 


= 


第 39 章 ” 云 存储 


通过 云 存 储 ， 将 个 人 数据 备份 在 网 络 上 是 非常 吸引 人 的 服务 ， 比 较 
著名 的 公司 或 产 
Syncplicity 所 等 。 这 些 产品 的 特点 是 能 够 和 操作 系统 的 shell 整 合 ， 例 如 
和 Windows 的 资源 管理 器 或 Linux 上 的 nautilus 整 合 ， 当 本 地 数据 有 改动 
时 会 自动 同步 到 远程 的 “ 云 存储 ”上 。 用 户 可 以 在 多 个 计算 机 或 手持 设备 
上 配置 和 同一 个 “云端 ”的 账号 同步 ， 从 而 实现 在 多 个 计算 机 或 多 个 手持 
设备 上 的 数据 同步 。 


品 有 Dropbox 0 、Surgarsync ”| 、Live Mesh 1 、 





[1] https:/ /www.dropbox.com/ 
[2] https://www.sugarsync.com/ 
[3] https://www.mesh.com/ 


[4] http:/ /www.syncplicity.com/ 


39.1 现 有 云 存 储 的 问题 


遗憾 的 是 我 并 未 使 用 过 上 述 云 存储 服务 ， 主 要 是 文 持 Linux 操 作 系 
统 的 云 存储 客户 端 比 较 少 ， 或 者 即使 有 也 因为 网 络 的 局 限 而 无 法 访问 ， 
但 是 可 以 通过 相关 文档 了 解 到 其 实现 的 机 理 。 


` 仅 支持 对 部 分 历史 数据 的 备份 。 


Dropbox 文 持 30 天 数据 备份 ，Surgarsync 每 个 文件 仅 保 留 5 个 备份 
《对 于 付费 用 户 ) ， 对 于 免费 用 户 仅 保 留 2 个 备份 。 
. 数据 同步 对 网 络 带宽 的 依赖 比较 让 


将 
TeJ o 


云端 ”被 多 个 设备 共享 ， 冲 突 解决 比较 困难 。 





Surgarsync 会 将 冲突 的 文件 自动 保存 为 多 份 ， 造 成 磁盘 空间 超出 配 
额 。 其 他 有 的 产品 在 过 到 冲突 时 停止 同步 ， 让 用 户 决 定 选择 哪个 版 本 。 


在 介绍 Git 的 书 里 介绍 云 存 储 ， 是 因为 上 述 云 存储 实现 和 Git 有 关 
吗 ? 不 是 。 实 际 上 通过 上 面 各 个 云 存 储 软件 特性 的 介绍 ， 有 经 验 的 
Linux 用 户 会 感觉 这 些 产 品 在 数据 同步 时 和 Linux 下 的 rsync、unison 等 数 


据 同步 工具 非 党 类似， 也许 只 是 在 服务 器 端 增加 了 历史 备份 而 已 。 





己 经 有 用 户 尝 试 将 云 存 储 和 Git 结 合 使 用 ， 就 是 将 Git 库 本 身 放 在 本 


机 的 云 存 储 同 步 区 〈 如 Dropbox 目 录 下 ) ，Git 库 被 同步 至 云端 。 即 用 云 
存储 作为 二 传 手 ， 实 际 上 还 是 基于 本 地 协议 操作 Git。 这 样 实际 上 是 会 
有 问题 的 。 





` 如 果 两 台 机 器 各 自 进行 了 提交 ， 云 存储 同步 一 定 会 引发 冲突 ， 这 


种 冲突 是 难以 解决 的 。 


` 云端 对 Git 的 每 个 文件 都 进行 备份 ， 包 括 执行 git gc 命令 打包 后 丢 
弃 掉 的 松散 对 象 。 这 实际 对 于 Git 是 不 需要 的 ， 会 浪费 本 来 就 有 限 的 空 


间 配 额 。 


“ 因为 版 本 库 操作 触发 的 git gc--auto 命 令 会 周期 性 地 整理 版 本 库 ， 
从 而 导致 即使 Git 版 本 库 的 一 个 小 提交 也 可 能 会 触发 大 量 的 云 存储 数据 
传输 。 


39.2 ”Git 式 云 存 储 畅 想 


GitHub 是 Git 风 格 的 云 存 储 ， 但 缺乏 像 之 前 提 到 的 云 存储 提供 的 傻 
瓜 式 服务 ， 只 有 Git 用 户 才 能 真正 利用 好 ， 这 大 大 限制 了 Git 在 云 存 储 领 
域 的 推广 。 下面 是 我 的 一 个 预言 : 一 个 结合 了 Git 和 傻瓜 式 云 存储 的 网 
络 存储 服务 终 将 诞生 。 新 的 傻瓜 式 云 存 储 将 有 下 列 特征 : 





1. 差 异同 步 传 输 


用 户 体 验 最 为 关键 的 是 网 络 传输 ， 如 果 用 Git 可 以 在 同步 时 实现 仅 
对 文件 差异 进行 数据 传输 ， 会 大 大 提高 同步 效率 。 之 所 以 现 有 的 在 线 备 
份 系统 实现 不 了 “差异 同步 传输 ”， 是 因为 没有 在 本 地 对 上 一 次 同步 时 的 
数据 做 备份 ， 只 能 通过 时 间 惟 或 文件 的 哈 硕 值 判断 文件 是 否 改变 ， 而 无 
法 得 出 文件 修改 前 后 的 差异 。 








可 以 很 容易 地 测试 云 存储 软件 的 网 络 传输 性 能 。 准 备 一 个 大 的 压缩 
包 (使 同步 时 的 压缩 传输 可 以 忽略 )， 测 试 一 下 同步 时 间 。 再 在 该 文件 
后 面 奶 加 几 个 字 节 ， 然 后 检查 同步 时 间 。 比 较 前 后 两 个 时 间 ， 就 可 以 看 
出 同步 是 否 实现 了 仪 针 对 差异 的 同步 传输 。 








2. 可 预测 的 本 地 及 云端 存储 空间 的 占用 


要 想 实现 前 面 提 到 的 差异 同步 传输 ， 束 必须 在 本 地 保存 上 一 次 同步 


时 文件 的 备份 。Subversion 是 用 一 份 元 余 的 本 地 拷贝 实现 的 ， 这 样本 地 
存储 大 小 是 实际 文件 的 两 倍 。Git 在 本 地 是 完全 版 本 库 ， 占 用 空间 的 逐 
渐 增 加 会 变 得 不 可 预测 。 





使 用 Git 实 现 云 存 储 ， 束 要 解决 在 本 地 及 在 服务 器 端 空间 占用 不 可 
预测 的 问题 。 对 于 服务 器 端 ， 可 以 采用 前 面 介 绍 的 Gistore 软 件 重 整 版 本 
库 的 方法 ， 或 者 通过 基于 历史 版 本 重建 提交 然后 变 基 来 实现 提交 数量 的 
删 减 。 对 于 客户 器 来 说 ， 只 保留 一 个 提交 就 够 了 ， 类 似 Subversion 的 文 
件 的 原始 拷贝 ， 这 就 需要 在 客户 端 基于 Git 原 理 重 新 实现 。 














3. 更 高 效 的 云端 存储 效率 








现 有 的 云 存储 效率 不 高 ， 很 有 可 能 因为 元 余 备 份 而 导致 存储 超过 配 
额 ， 即 使 服务 提供 商 的 配额 计算 是 以 最 后 一 个 版 本 计算 的 ， 实 际 的 磁盘 
占用 还 是 很 可 观 的 。 





Git 底 层 实现 了 一 个 对 内 容 跟 踪 的 文件 系统 ， 相 同 内 容 的 文件 即使 
文件 名 和 目录 不 同 ， 在 Git 看 来 都 是 一 个 对 象 并 用 一 个 文件 存储 (文件 
名 是 内 容 相 关 的 SHA1 哈 希 值 )。 因 此 Git 方 式 实 现 的 云 存 储 在 空间 的 节 
省 上 有 先天 的 优势 。 








4. 目 动 进行 冲突 解决 


冲突 解决 是 和 文件 同步 相关 的 ， 只 有 通过 人 
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步 的 性 能 瓶 陆 ， 才 能 为 冲突 解决 打下 基础 。 先 将 冲突 的 各 个 版 本 都 同步 
到 本 地 ， 然 后 进行 自动 冲突 解决 ， 如 果 冲 突 无 法 自动 解决 ， 再 提示 用 户 
手工 解决 冲突 。 还 有 ， 如 果 在 手工 冲突 解决 时 引入 类 似 kdiff3 一 样 的 工 
上 其， 对 用 户 会 更 有 了 吸引 力 。 


5.Git 提 交 中 引入 特殊 标识 








如 果 使 用 变 基 或 其 他 技术 实现 备份 提交 数量 的 删 减 ， 束 会 在 云 病 的 
提交 与 本 地 数据 的 合并 上 产生 问题 。 可 以 通过 为 提交 引入 特殊 的 唯一 性 
标识 ， 不 随 着 Git 变 基 而 改变 ， 束 像 在 Gerrit 中 的 Change-Id 标 签 一 样 。 





我 相信 ， 基 于 Git 的 文件 系统 及 传输 机 理 可 以 实现 一 个 更 好 用 的 云 
存储 服务 站。 


[1] 在 本 书 基本 完稿 时 ， 听 说 了 一 个 名 为 SparkleShare 的 项 目 ， 似乎 就 是 
一 个 基于 Git 的 云 存储 方案 。 网 址 : http://spatkleshare.org/。 


第 8 篇 ”Git 杂 谈 





Git 有 着 非常 庞杂 的 命令 集 和 功能 ， 到 目前 为 止 尚 有 一 些 命令 及 要 
点 还 没有 介绍 。 在 构思 本 书 的 过 程 中 ， 我 尝试 用 FreeMind 软 件 将 准备 讲 
述 的 Git 的 各 个 命令 和 要 后 在 各 个 章节 之 间 拖 动 ， 以 期 在 内 容 上 更 加 元 
实 ， 组 织 上 更 加 合理 ， 讲 述 上 更 加 方便 ， 但 最 终 还 是 剩 下 了 一 些 Git 命 
令 和 要 点 没有 安排 在 前 面 的 章节 中 。 于 是 这 些 不 常用 的 Git 命 令 和 要 点 
(缺乏 它们 会 影响 一 本 被 冠 以 “权威 指南 ”的 书 的 完备 性 〉 放 在 本 书 的 最 
后 “Git 杂 谈 ” 中 予以 讲述 。 




















本 篇 首先 用 一 半 的 内 容 来 介绍 跨 平台 项 目 在 使 用 Git 时 应 注意 的 事 
项 ， 包 括 字 符 集 问题 、 文 件 名 大 小 写 问 题 、 文 本 文件 换行 符 问 题 。 然 
后 ， 接 下 来 的 一 章 会 概要 介绍 本 书 到 目前 为 止 沿 未 涉猎 到 的 Git 话 题 和 
相关 命令 ， 如 : 属性、 钩子 、 模 板 、 稀 芷 检 出 、 浅 死 隆 及 尹 接 ， 还 会 介 


绍 git replace 和 git notes 等 命令 。 





第 40 草 ”路 平台 操作 Git 


您 是 在 什么 平台 《操作 系统 ) 中 使 用 Git 呢 ? 图 40-1 是 网 上 发 布 的 一 
个 Git 使 用 平台 调查 结果 的 截图 上 ， 从 中 可 以 看 出 排 在 前 三 位 的 是 : 
Linux、Mac OS X 和 Windows。 而 Windows 用 户 中 又 以 使 用 msysGit 的 用 
户 居多 。 





On which operating system(s) do You Use Git? 


GNU/Linux 85% 7243 
*BSD (FreeBSD, OpenBSD, Net8SD, etc.) 7% 639 
MacOS X (Darwin) 46% 3932 
MS Windows/Cygwin 10% 23 
MS Windows/msysGit (MINGW) 25% 2151 
other Unix 211 
Other, please specify 196 117 
Total respondents 8542 

Respondents who skipped this question 299 


图 40-1 ”Git 用户 操作 系统 使 用 分 布 图 


在 如 今 手 持 设备 争夺 激烈 的 年 代 ， 在 什么 操作 系统 上 进行 软件 开发 
工作 已 经 变 得 不 那么 重要 了 ， 很 多 手持 设备 都 提供 可 以 运行 在 各 种 主流 
操作 系统 上 的 虚拟 器 ， 因 此 一 个 项 目 团队 的 成 员 根 据 各 目的 使 用 习惯 ， 
可 能 使 用 不 同 的 操作 系统 。 当 一 个 团队 中 不 同 的 成 员 在 不 同 的 平台 中 使 
用 Git 进 行 交 互 时 ， 可 能 会 遇 到 平台 兼容 性 的 问题 。 

















即使 团队 成 员 都 在 同一 种 操作 系统 上 工作 〈 如 Windows) ， 但 Git 服 
务 器 可 能 架设 在 另外 的 平台 上 (如 Linux) ， 或 者 产品 的 源 代 码 被 分 发 
到 另外 的 平台 上 进行 编译 、 部 普 ， 同 样 都 会 过 到 平台 兼容 性 的 问题 。 


[1] http:/ /www.survs.com/results/33Q0O0ZZE/MV653KSPI2 


40.1 字符 集 问 题 


本 书 第 1 篇 “第 3 章 安装 Git* 就 已 经 详细 介绍 了 不 同 平台 对 本 地 字符 集 
(如 中 文 ) 的 支持 情况 ， 本 章 将 再 做 一 次 简单 的 概述 。 


Linux、Mac OS X 及 Windows 下 的 Cygwin 默 认 使 用 UTF-8 字 符 集 。 
Git 运 行 在 这 些 平台 下 ， 能 够 使 用 本 地 语言 (如 中 文 ) 写 提交 说 明 、 命 
名 文件 ， 其 至 使 用 本 地 语言 命名 分 支 和 里 程 碑 。 在 这 些 平台 上 唯一 要 做 
的 就 是 对 Git 进 行 如 下 设置 ， 以 便 使 用 了 本 地 语言 (如 中 文 ) 命名 文件 
后 ， 能 够 在 状态 查看 、 差 异 比较 时 正确 地 显示 文件 名 。 











$ git config --global core.quotepath false 





但 是 如 果 在 Windows 平 台 使 用 msysGit， 或 者 在 其 他 平台 使 用 非 
UTF-8 字 符 集 ， 要 想 使 用 本 地 语言 撰写 提交 说 明 、 命 名 文件 名 和 目录 名 
就 非常 具有 挑战 性 了 。 例 如 对 于 使 用 GBK 字 符 集 的 中 文 Windows， 需 要 
为 Git 进 行 如 下 设置 ， 才 能 够 在 提交 说 明 中 正确 地 使 用 中 文 。 








$ git config --system core.quotepath false 
$ git config --system ii8n.commitEncoding gbk 
$ git config --system i1i8n.logOutputEncoding gbk 





当 像 上 面 那样 设置 i18n.commitEncoding 后 ， 如 果 执 行 提 交 ， 就 会 在 
提交 对 象 中 舱 入 编码 设置 的 指令 。 例 如 在 Windows 中 使 用 msysGit 执 行 一 





次 提交 ， 在 Linux 上 使 用 git cat-file 命 令 查 看 提交 时 会 出 现 乱 码 ， 需 要 使 
用 iconv 命 令 对 输出 进行 字符 集 转换 ， 才 能 正确 得 看 该 提交 对 象 。 从 下 
面 输出 的 倒数 第 三 行 可 以 看 到 encoding gbk 这 条 对 字符 集 进行 设置 的 指 


令 。 








$ git cat-file -p HEAD | iconv -f gbk -t utf-8 

tree 00e814cda96ac016bcacabcf4c8a84156e304ac6 

parent 52e6454db3d99c85b1b5a00ef987f8fc6d28c020 

author Jiang Xin <jiangxin@ossxp.com> 1297241081 +0800 
committer Jiang Xin <jiangxin@ossxp.com> 1297241081 +0800 
encoding gbk 

添加 中 文 说 明 。 





因为 在 提交 对 象 中 声明 了 正确 的 字符 集 ， 因 此 在 Linux 下 可 以 用 git 
log 命 令 正 确 显 示 msysGit 生 成 的 包含 中 文 的 提交 说 明 。 


但 是 对 于 非 UTF-8 字 符 集 平台 《如 msysGit) ，Git 当 前 版 本 
(1.7.4) 对 使 用 本 地 字符 《〈 如 中 文 ) 命名 文件 或 目录 的 文 持 尚 不 完善 。 
文件 名 和 目录 名 实际 上 是 写 在 树 对 象 中 的 ，Git 在 创建 树 对 象 时 ， 以 本 
地 字符 集 而 非 UTF-8 字 符 集 进行 保存 ， 因 而 在 路 平台 时 会 造成 文件 名 乱 
码 。 例 如 下 面 的 示例 显示 的 是 在 Linux 平 台 (UTF-8 字 符 集 〉 下 查看 由 
msysGit 提 交 的 包含 中 文 文件 的 树 对 象 。 注 意 要 在 git cat-file 命 令 的 后 面 
通过 管道 符号 调用 iconv 命 令 进行 字符 转换 ， 人 否则 不 能 正确 地 显示 中 
文 。 如 果 直 接 在 Linux 平 台 检 出 ， 检 出 的 文件 名 显示 为 乱码 。 

















$ git cat-file -p HEAD^{tree} | iconv -f gbk -t utf-8 
100644 blob 8cob112f56b3b9897007031ea38c130b0b161d5a 说 明 .txt 





40.2 ”文件 名 大 小 写 问 题 


Linux、Solaris、BSD 及 其 他 类 Unix 操 作 系 统 使 用 的 是 大 小 写 敏感 的 
文件 系统 ， 而 Windows 和 Mac OS X〔 默 认 安 装 ) 的 文件 系统 则 是 大 小 写 
不 敏感 的 文件 系统 。 即 用 文件 名 README、readme 及 Readme (混合 
小 写 ) 进行 访问 ， 在 Linux 等 操作 系统 上 访问 的 是 不 同 的 文件 ， 而 在 
Windows 和 Mac OS X 上 则 指向 同一 个 文件 。 换 句 话 说， 不 同 的 文件 
README 、readme 及 Readme 在 Linux 等 操作 系统 上 可 以 共存 ， 而 在 
Windows 和 Mac OS X 上 ， 这 些 文件 只 能 同时 存在 一 个 ， 另 外 的 会 被 覆 
盖 ， 因 为 在 大 小 写 不 敏感 的 操作 系统 看 来 ， 这 些 文件 是 同一 个 文件 。 














如 果 在 Linux 上 为 Git 版 本 库 添加 了 两 个 文件 名 仅 大 小 写 不 同 的 文件 
(文件 内 容 各 不 相同 ) ， 如 README 和 readme。 当 推送 到 服务 器 的 共享 
版 本 库 上 ， 并 在 文件 名 大 小 写 不 敏感 的 操作 系统 中 克隆 或 同步 时 ， 就 会 
出 现 问 题 。 例 如 在 Windows 和 Mac OS X 平 台 上 执行 git clone 后 ， 在 本 地 
工作 区 中 出 现 两 个 同名 文件 中 的 一 个 ， 而 另外 一 个 文件 会 被 覆盖 ， 这 就 
会 导致 Git 对 工作 区 中 的 文件 造成 误 判 ， 在 提交 时 会 导致 文件 内 容 被 破 
坏 。 





当 一 个 项 目 存在 跨 平 合 开发 的 情况 时 ， 为 了 避免 这 类 问题 的 发 生 ， 
在 一 个 文件 名 大 小 写 敏感 的 操作 系统 (如 Linux〉 中 克隆 版 本 库 后 ， 应 








立即 对 版 本 库 进行 如 下 设置 ， 让 版 本 库 的 行为 好 似 对 文件 名 大 小 写 不 敏 


$ git config core.ignorecase true 


Windows 和 Mac OS X 在 初始 化 一 个 版 本 库 或 元 隆 一 个 版 本 库 时 ， 会 
自动 在 版 本 库 中 包含 配置 变量 core.ignorecase 为 true 的 设置 ， 除 非 版 本 库 
不 是 通过 克隆 而 是 直接 从 Linux 上 拷贝 而 来 的 。 


当 版 本 库 包含 了 core.ignorecase 为 true 的 配置 后 ， 文 件 名 在 文件 添加 
时 便 被 唯一 确定 。 如 果 之 后 修改 文件 内 容 的 同时 又 修改 了 文件 名 中 字母 
的 大 小 写 ， 只 会 被 视 为 对 文件 内 容 的 修改 ， 执 行 提交 不 会 改变 文件 名 。 
如 果 对 添加 文件 时 设置 的 文件 名 的 大 小 写 不 满意 ， 确 实 需要 对 文件 重合 
名 ， 对 于 Linux 来 说 很 简单 ， 直 接 运行 git mv 命令 显 式 地 对 文件 进行 重 命 
名 操作 。 例 如 执行 下 面 的 命令 就 可 以 将 changelog 文 件 的 文件 名 修改 为 
ChangeLog。 





$ git mv changelog ChangeLog 
$ git commit 


但 是 对 于 Windows 和 Mac OS X 却 不 能 这 么 操作 ， 因 为 Git 会 拒绝 这 
样 的 重 命名 操作 : 





$ git mv changelog ChangeLog 
fatal: destination exists, source=changelog, destination=ChangeLog 








而 需要 像 下 面 这 样 ， 先 将 文件 重 命名 为 妃 外 的 一 个 名 称 ， 再 执行 一 
次 重 命名 改 回 为 正确 的 文件 名 ， 如 下 : 








$ git mv changelog non-exist-filename 
$ git mv non-exist-filename ChangeLog 
$ git commit 





40.3 ”换行 符 问 题 


每 一 个 通用 的 版 本 控制 系统 ， 无 论 是 CVS、Subversion、Git， 还 是 
其 他 ， 都 要 面 对 换 行 符 转 换 的 问题 。 这 是 因为 作为 通用 的 版 本 控制 系 
统 ， 一 定 会 面 对 来 自 不 同 操作 系统 的 文件 ， 而 不 同 的 操作 系统 在 处 理 文 
本 文件 时 ， 可 能 使 用 不 同 的 换行 符 。 


1. 不 同 的 操作 系统 可 能 使 用 不 同 的 换行 符 


文本 文件 的 每 一 行 结尾 都 用 一 个 或 两 个 特殊 的 ASCI 字 符 进 行 标 
识 ， 这 个 标识 就 是 换行 符 。 主 要 的 换行 符 有 三 种 : LF (line feed 即 换 
行 ，C 语 言 等 用 \n 表 示 ， 相 当 于 十 六 进 制 的 0x0A) 、CR (Carriage 
return 即 回 车 ，C 语 言 等 用 表示 ， 相 当 于 十 六 进 制 的 Oox0D) 和 
CRLF《〈 即 由 两 个 字符 CR+LF 组 成 ， 即 "em"， 相 当 于 十 六 进 制 的 0x0D 
0x0A) ， 分 别 用 在 不 同 的 操作 系统 中 由 。 





[IF 换行 符 : 用 于 Multics、Unix、 类 Unix (如 GNU/Linux、AIX、 
Xenix、Mac OS X、FreeBSD 等 ) 、BeOS、Amiga、RISC OS 等 操作 系统 
中 。 


. CRLF 换 行 符 : 用 于 DEC TOPS-10、RT-11 和 其 他 早期 的 非 Unix， 


以 及 CP/M、MP/M、DOS (MS-DOS、PC-DOS 等 ) 、Atari TOS、 


OS/2、Microsoft Windows、Symbian OS、Palm OS 等 系统 中 。 


.CR 换行 符 : 用 于 Commodote 8 位 机 、TRS-80、 苹 果 芽 家 族 、Mac 
OS 9 及 更 早 版 本 。 


实际 上 ， 自 从 苹果 的 Mac OS 从 第 10 版 转向 Unix 内 核 开 始 ， 依 据 不 
同 的 文本 文件 换行 符 ， 主 流 的 操作 系统 可 以 划分 为 两 大 阵营 : 一 个 是 微 
软 Windows 作 为 一 方 ， 使 用 CRLF 作 为 换行 符 ， 男 外 一 方 包括 Unix、 类 
Unix( 如 Linux 和 Mac OS X 等 ) 使 用 LF 作为 换行 符 。 分 属 不 同 阵 营 的 操 
作 系 统 之 间 交 换文 本 文件 会 因为 换行 人 符 的 不 同 而 造成 障碍 ， 而 使 用 版 本 
控制 系统 ， 也 同样 会 遇 到 换行 符 的 厅 烦 : 


` 编辑 器 不 能 识别 换行 符 ， 可 能 会 显示 为 特殊 字符 ， 如 Linux 上 的 
编辑 器 显示 的 ^M 特 殊 字符 ， 就 是 拜 Windows 的 CRLF 换 行 符 所 赐 。 或 者 
丢弃 换行 符 ， 如 来 自 Linux 的 文本 文件 ， 在 Windows 上 打开 可 能 会 因为 识 
别 不 了 换行 符 ， 导 致 所 有 的 行 合并 在 一 起 。 


` 版 本 库 中 的 文件 被 来 自 不 同 操作 系统 的 用 户 改 来 改 去 ， 在 某 一 次 
提交 中 换行 符 为 LF， 在 下 一 次 提交 中 被 蔡 换 为 CRLF， 这 不 但 会 在 查看 
文件 版 本 间 的 差异 时 造成 困惑 (所 有 的 行 都 显示 为 变更 ) ， 还 会 给 版 本 
库 的 存储 营 来 不 必要 的 宛 余 。 


“ 可 能 会 在 一 个 文件 中 引入 混杂 的 换行 符 ， 即 有 的 行 是 LF， 而 有 的 


行 是 CRLF。 无 论 在 哪个 操作 系统 中 用 编辑 器 打开 这 样 的 文件 ， 或 多 或 


少 都 会 感到 困惑 。 


:如果 版 本 控制 系统 提供 文本 文件 换行 符 的 自动 转换 ， 在 Windows 
平台 将 版 本 库 文件 导出 为 源码 包 并 发 布 ， 当 该 源码 包 被 Linux 用 户 下 载 


后 ， 编 译 、 运 行 可 能 会 有 问题 ， 反 之 亦 然 。 


2. 文 件 类 型 判别 ， 是 换行 符 转 换 的 基础 


几乎 所 有 的 版 本 库 控制 系统 都 采用 这 样 的 解决 方案 : 对 于 文本 文 
件 ， 在 版 本 库 中 保存 时 换行 符 使 用 LF， 当 从 版 本 库 检 出 到 工作 区 时 ， 则 
根据 平台 的 不 同 或 用 户 设置 的 不 同 ， 来 对 文本 文件 的 换行 符 进行 转换 
(转换 为 LF、CR 或 CRLF) 。 








为 什么 换行 符 转 换 要 特意 强调 文本 文件 呢 ? 这 是 因为 如 果 对 二 进 制 
文件 “程序 或 数据 ) 当中 出 现 的 换行 符 进 行 上 述 转换 ， 会 导致 二 进 制 文 
件 被 破坏 。 因 此 判别 文件 类 型 是 文本 文件 还 是 二 进 制 文件 ， 是 进行 文件 
换行 符 正 确 转 换 的 基础 。 








有 的 版 本 控制 系统 ， 如 CVS， 必 须 在 添加 文件 时 人 为 地 设 定 文 件 类 
型 《用 -kb 参数 设 定 二 进 制 文件 ) ， 一 旦 用 户 忘记 对 二 进 制 文件 进行 标 
记 ， 就 会 造成 二 进 制 文件 被 破坏 。 这 种 破坏 有 时 会 藏 得 比较 深 ， 例 如 在 
Linux 上 检 出 文件 一 切 正常 ， 因 为 版 本 库 中 被 误 判 为 文本 文件 的 图 形 文 
件 中 所 包含 的 字符 0x0A 在 Linux 上 检 出 时 没有 改变 ， 但 是 在 Windows 上 
检 出 时 会 导致 图 形 文件 中 的 0x0A 字 符 被 转换 为 0x0D 0x0A 两 个 字符 ， 从 








而 造成 图 片 被 破坏 。 


有 的 版 本 控制 系统 可 以 自动 识别 文本 文件 和 二 进 制 文件 ， 但 是 识别 
算法 存在 问题 。 例 如 Subversion 检 查 文件 的 前 1024 字 节 的 内 容 ， 如 果 其 
中 包含 NULL 字 符 〈0x00) ， 或 者 超过 15% 的 字符 是 非 ASCII 字 符 ， 则 
Subversion 认 定 此 文件 为 二 进 制 文件 所 。 这 种 算法 会 将 包含 大 量 中 文 的 
文本 文件 当 作 二 进 制 文件 ， 不 进行 换行 符 转 换 ， 也 不 进行 版 本 间 的 比较 
《除非 强制 执行 ) 。 


Git 显 然 比 Subversion 更 了 解 这 个 世界 上 文字 的 多 样 性 ， 因 此 在 判别 
二 进 制 文件 上 没有 多 余 的 判别 步 又， 只 对 blob 对 象 的 前 8000 个 字符 进行 
检查 ， 如 果 其 中 出 现 NULL 字 符 〈0x00) 则 当 作 二 进 制 文件 ， 和 否则 为 文 
本 文件 中 。Git 还 允许 用 户 通过 属性 文件 对 文件 类 型 进行 设置 ， 属 性 文 
件 设置 优先 。 





Git 默 认 并 不 开局 文本 文件 的 换行 符 转 换 ， 因 为 毕竟 Git 对 文件 是 否 
征 二 进 制 文件 所 做 的 猜测 存在 误 判 的 可 能 。 如 果 用 户 通过 属性 文件 或 其 
他 方式 显 式 地 对 文件 类 型 进行 了 设置 ， 则 Git 束 会 对 文本 文件 开局 换行 
从 转换 。 





下 面 是 一 个 属性 文件 的 示例 ， 为 方便 描述 标 以 行 写 。 


1 txt text 

2 vcproj eol=crilf 
3 S eol=1f 

4 jpg -text 


5 *,jpeg binary 





包含 了 上 面 属性 文件 的 版 本 库 ， 会 将 以 .Ext\、.Vcproj、.sh 为 扩展 名 
的 文件 视 为 文本 文件 ， 在 处 理 过 程 中 会 进行 换行 符 转 换 ， 而 将 
以 .jpg、.jpeg 为 扩展 名 的 文件 视 为 二 进 制 文件 ， 不 进行 换行 符 转 换 。 


3. 依 据 属性 文件 进行 换行 符 转 换 


关于 属性 文件 ， 会 在 后 面 的 章节 详细 介绍 ， 现 在 可 以 将 其 理解 为 工 
作 区 目录 下 的 .gitattributes 文 件 ， 其 文件 匹配 方法 及 该 文件 的 作用 范围 
和 .gitignore 文 件 非常 类 似 。 


像 上 面 的 属性 文件 示例 中 ， 第 1 行 设 置 了 扩展 名 为 .txt 的 文件 具有 
text 属 性 ， 则 所 有 扩展 名 为 .fxt 的 文件 添加 到 版 本 库 时 ， 在 版 本 库 中 创建 
的 blob 文 件 的 换行 符 一 律 被 转换 为 LF。 而 当 扩 展 名 为 .txt 的 文件 检 出 到 
工作 区 时 ， 则 根据 平台 的 不 同 而 使 用 不 同 的 换行 符 ， 如 在 Linux 上 检 出 
则 使 用 LF 换行 符 ， 如 在 Windows 上 检 出 则 使 用 CRLF 换 行 符 。 


示例 中 的 第 2 行 设置 扩展 名 为 .vcproj 的 文件 的 属性 eol 的 值 为 elf， 隐 
含 着 该 文件 属于 文本 文件 的 含义 ， 当 向 版 本 库 添加 扩展 名 为 .vcproj 的 文 
件 时 ， 在 版 本 库 中 创建 的 blob 文 件 的 换行 符 一 律 转 换 为 LF。 而 当 该 类 型 
的 文件 检 出 到 工作 区 时 ， 则 一 律 使 用 CRLF 作 为 换行 符 ， 不 管 是 在 
Windows 上 检 出 ， 还 是 在 Linux 上 检 出 。 











同 理 示 例 中 的 第 3 行 设 置 的 扩展 名 为 .sh 的 文件 也 会 进行 类 似 的 换行 
和 从 转换 ， 区 别 在 于 该 类 型 文件 无 论 在 哪个 平台 检 出 ， 都 使 用 LF 作为 换行 


符 


像 上 面 那样 逐一 为 不 同类 型 的 文件 设置 换行 符 格 式 显 得 很 抹 烦 ， 可 
以 在 属性 文件 中 添加 下 面 的 设置 ， 为 所 有 文件 开局 文件 类 型 自动 判断 。 











* text=auto 





当 为 所 有 文件 设置 了 text=auto 的 属性 后 ，Git 就 会 在 文件 检 入 和 检 出 
时 对 文件 是 否 是 二 进 制 进行 判断 ， 采 用 前 面 提 到 的 方法 : 如 果 文 件 头 部 
的 8000 个 字符 中 出 现 NULL 字 符 则 为 二 进 制 文件 ， 和 否则 为 文本 文件 。 如 
果 判 断 文件 是 文本 文件 就 会 启用 换行 符 转 换 。 至 于 本 地 检 出 文件 采用 什 
么 换行 符 格 式 ， 实 际 上 是 由 core.eol 配 置 变量 进行 设置 的 ， 不 过 因为 
core.eol 未 被 设置 时 会 采用 默认 值 native， 才 使 得 工作 区 文本 文件 的 检 出 
采用 操作 系统 默认 的 换行 符 格 式 。 配 置 变量 core.eol 除 了 默认 的 native 
外 ， 还 可 以 使 用 {f 和 crlf， 不 过 一 般 较 少 用 到 。 











4. 使 用 Git 配 置 变量 控制 换行 符 转 换 

在 Git 1.7.4 之 前 ， 用 属性 文件 的 方式 来 设置 文件 的 换行 符 转 换 ， 只 
能 逐一 为 版 本 库 进 行 设置 ， 如 果 要 为 本 地 所 有 的 版 本 库 设 定 文件 换行 符 
转换 就 非常 豚 烦 。Git 1.7.4 提 供 了 全 局 可 用 的 属性 文件 ， 实 现 了 对 换行 





符 转 换 设 定 的 全 局 控制 ， 我 们 会 在 后 面 的 章节 了 予以 介绍 。 现 在 介绍 男 外 
一 个 方法 ， 即 通过 配置 变量 core.autocrlf 来 开启 文本 文件 换行 符 转 换 的 功 
能 。 例 如 执行 下 面 的 命令 ， 对 配置 变量 core.autocrlf 进 行 设置 : 





$ git config --global core.autocrlf true 





默认 Git 不 对 配置 变量 core.autocrlf 进 行 设置 ， 同 时 如 果 没 有 通过 属 
性 文件 指定 文件 的 类 型 ，Git 不 对 文件 进行 换行 符 转 换 。 但 是 将 配置 变 
量 core.autocrlf 设 置 为 下 列 值 时 ， 会 开启 Git 对 文件 类 型 的 智能 判别 并 对 
文本 文件 执行 换行 符 转 换 。 





. 设置 配置 变量 cote.autoctlf 为 true。 


效果 束 相 当 于 为 版 本 库 中 的 所 有 文件 设置 了 text=auto 的 属性 。 即 通 
过 Git 对 文件 类 型 的 自动 判定 ， 对 文本 文件 进行 换行 符 转 换 。 在 版 本 库 
的 blob 文 件 中 使 用 LE 作为 换行 符 ， 而 检 出 到 工作 区 时 无 论 是 什么 操作 系 
统 都 使 用 CRLF 为 换行 符 。 注 意 当 设置 了 core.autocrlf 为 tue 时 ， 会 忽略 
core.eol 的 设置 ， 工 作 区 文件 始终 使 用 CRLF 作 为 换行 行 ， 这 对 于 
Windows 下 的 Git 非 第 适合 ， 但 不 适用 于 Linux 等 操作 系统 。 











` 设置 配置 变量 core.autocrlf 为 Input。 


同样 开局 文本 文件 的 换行 符 转换 ， 但 只 是 在 文件 所 交 到 版 本 库 时 ， 
将 新 增 入 库 的 blob 文 件 的 换行 符 转 换 为 LF。 如 果 将 文件 从 版 本 库 检 出 到 





工作 区 ， 则 不 进行 文件 转换 ， 即 版 本 库 中 的 文件 若是 采用 LF 换 行 符 ， 检 
出 仍旧 是 LF 作为 换行 符 。 这 个 设置 对 Linux 等 操作 系统 下 的 Git 非 常 适 
合 ， 但 不 适合 于 Windows。 


5. 换 行 符 转 换 的 异常 捕获 





无 论 用 户 是 通过 属性 文件 来 设 定 文件 的 类 型 ， 还 是 通过 Git 智 能 判 
别 ， 都 可 能 错误 地 将 二 进 制 文件 识别 为 文本 文件 ， 在 转换 过 程 中 造成 文 
件 的 破坏 。 有 一 种 情况 下 的 破坏 最 为 严重 ， 就 是 误 判 的 文件 中 包含 不 一 
致 的 换行 符 《〈 既 有 CRLF， 又 有 LF) ， 这 将 会 导致 保存 到 版 本 库 中 的 
blob 对 象 无 论 通 过 何 种 转换 方式 都 不 能 还 原 回 原 有 的 文件 。 








Git 提 供 了 名 为 core.safecrlf 的 配置 变量 ， 可 以 用 于 捕获 这 种 不 可 逆 
的 换行 符 转换 ， 以 提醒 用 户 注 意 。 将 配置 变量 core.safecrlf 设 置 为 true 
时 ， 如 果 发 现存 在 不 可 逆 换 行 符 转 换 ， 会 报错 退出 ， 拒 绝 执 行 不 可 逆 的 
换行 符 转 换 。 如 果 将 配置 变量 core.safecrlf 设 置 为 wam 则 人 允许 不 可 逆 的 转 
换 ， 但 发 现 不 可 逆转 换 时 会 发 出 警告。 


[1] http:/ /en.wikipedia.org/wiki/ Newline 
思 ] 参见 Subversion 源 代码 subversion/libsvn_subr/io.c 中 的 
svn_io_detect_mimetype2 牵 数 。 


[3] 参见 Git 源 代码 xdqdiff-intetface.c 中 的 buffet_is_binaty 函 数 。 


第 41 章 ”Git 的 其 他 特性 


41.1 属性 





Git 通 过 属性 文件 为 版 本 库 中 的 文件 或 目录 添加 属性 。 设 置 了 属性 
的 文件 或 目录 ， 在 执行 Git 相 关 操 作 时 会 做 特殊 处 理 ， 正 如 之 前 介绍 换 
行 符 转 换 时 设置 了 文本 属性 (text)〉 的 文件 那样 。 





41.1.1 属性 定义 


属性 文件 是 一 个 普通 的 文本 文件 ， 每 一 行 对 一 个 路 径 〈 可 使 用 通 配 
符 ) 设置 相应 的 属性 。 语 法 格式 如 下 : 


<pattern> <attr1i> <attr2> ... 


其 中 路 径 由 可 以 使 用 通配符 的 <pattern> 来 定义 ， 在 <pattern> 后 面 可 
以 设置 一 个 或 多 个 属性 ， 不 同 的 属性 之 间 用 空格 分 开 。 路 径 中 通配符 的 
用 法 和 文件 包 略 〈.gitignore) 的 语法 格式 相同 ， 参 见 本 书 第 2 篇 第 10 章 
的 “10.8 文 件 忽略 ”的 相关 内 容 。 下 面 以 text 属 性 为 例 来 介绍 属性 的 不 同 写 
法 : 








" text 


直接 通过 属性 名 进行 设置 ， 相 当 于 将 text 的 属性 值 设置 为 true。 


对 于 设置 Ttext 属 性 的 文件 ， 不 再 需要 Git 来 猜测 文件 的 类 型 ， 而 可 
以 直接 判定 为 文本 文件 并 进行 相应 的 换行 符 转 换 。 





” -text 





在 属性 名 前 用 减 写 标识 ， 相 当 于 将 text 的 属性 值 设 置 为 false。 





对 于 设置 了 取 反 text 属 性 的 文件 ， 直 接 判 定 为 二 进 制 文件 ， 在 文件 
检 入 和 检 出 时 不 进行 换行 符 转 换 。 


. | text 





在 属性 名 前 面 添 加 感叹 号 ， 相 当 于 没有 设置 该 属性 ， 既 不 等 于 
true， 也 不 等 于 false。 





对 于 未 定义 text 属 性 的 文件 ， 根 据 Git 是 否 配置 了 core.autocrlf 配 置 变 
量 来 决定 是 否 进 行 换 行 符 转换 。 因 此 对 于 ! text (没有 定义 text 属 性 ) 
和 -text (text 属 性 设置 取 反 ) ， 两 者 存在 差异 。 








"text 一 auUtoO 


属性 除了 上 述 true、false 和 未 设置 三 个 状态 外 ， 还 可 以 对 属性 用 相 
关 的 枚 举 值 (预定 义 的 字符 串 〉 进行 设置 。 不 同 的 属性 值 可 能 有 不 同 的 
枚 举 值 ， 对 于 text 必 性 可 以 设置 为 auto。 


对 于 text 属 性 设置 为 auto 的 文件 ， 文 件 类 型 实际 上 尚未 确定 ， 需 要 
Git 读 取 文 件 内 容 进行 智能 判别 ， 判 别 为 文本 文件 则 进行 换行 符 转 换 。 
显然 当 设 置 text 属 性 为 auto 时 ， 并 不 等 同 于 设置 为 true。 


41.1.2 属性 文件 及 优先 级 


属性 文件 可 以 以 .gitattributes 文 件 名 保存 在 工作 区 目录 中 ， 提 交 到 版 
本 库 后 就 可 以 和 其 他 用 户 共享 项 目 文件 的 属性 设置 。 属 性 文件 也 可 以 保 
存在 工作 区 之 外 ， 例 如 保存 在 文件 .gitinfo/attributes 中 ， 则 仅 对 本 版 本 库 
生效 ， 若 保存 在 /etc/gitattributes 中 文件 中 则 对 全 局 生效 。 在 查询 某 个 工 
作 区 某 一 文件 的 属性 时 ， 不 同位 置 的 属性 文件 具有 不 同 的 优先 级 ，Git 
依据 下 列 顺序 依次 访问 属性 文件 : 











(1) 文件 .gitinfo/attributes 具 有 最 高 的 优先 级 。 








(2) 接 下 来 检查 工作 区 同一 目录 下 的 .gitattributes， 并 依次 问 上 递 
归 碍 找 .gitattributes 文 件 ， 直 到 工作 区 的 根 目 录 。 


(3) 然后 查询 由 Git 的 配置 变量 core.attributesfile 指 定 的 全 局 属性 文 
件 。 


(4) 最 后 是 系统 属性 文件 ， 即 文件 $ (prefixz) /etc/gitattributes。 不 
同 的 Git 安 闭 方 式 下 这 个 文件 的 位 置 可 能 不 同 ， 但 是 该 文件 始终 和 Git 的 








系统 配置 文件 (可 以 通过 git config--system-e 命 令 打开 系统 配置 文件 从 而 
知道 其 位 置 ) 位 于 同一 目录 中 。 


注意 : 只 有 在 1.7.4 或 更 新 版 本 的 Git 中 才 提 供 后 两 种 (全 局 的 和 系 
统 级 的 ) 属性 文件 。 可 以 通过 下 面 的 例子 来 理解 属性 文件 的 优先 级 和 属 
性 设置 方法 。 


首先 来 看 看 某 个 版 本 库 及 系统 中 所 包含 的 属性 文件 : 


. 其 一 是 位 于 版 本 库 中 的 文件 .git/info/attributes， 内 容 如 下 : 





a* foo !bar -baz 





` 其 二 是 位 于 工作 区 子 目 录 t 下 的 属性 文件 ， 即 t/.gitattributes， 内 容 











如 下 : 
ab* merge=filfre 
abc -foo -bar 
ke frotz 
* 再 一 个 就 是 位 于 工作 区 根 目 录 下 的 属性 文件 .gitattributes ， 内 容 如 
国 
abc foo bar baz 





如 果 系 统 文件 /etc/gitconfig 中 包含 如 下 配置 ， 则 每 个 用 户主 目录 


下 的 .gitattributes 文 件 都 被 作为 全 局 属性 文件 。 





[core 
attributesfile = ~/. gitattributes 





` 位 于 用 户主 目录 下 的 属性 文件 ， 即 文件 ~/.gitattributes 的 内 容 如 





* text=auto 





当 但 询 工 作 区 文件 Vabc 的 属性 时 ， 根 据 属性 文件 的 优先 级 ， 按 照 下 
列 顺序 进行 检索 : 





(1) 先 检 查 属 性 文件 .giUinfo/attributes。 显 然 该 文件 中 唯一 的 一 行 
就 和 文件 Vabc 匹 配 ， 因 此 文件 Vvabc 的 属性 如 下 : 





foo : true 
bar : 未 设置 
baz : false 








(2) 再 检查 和 文件 UVabc 同 目录 的 属性 文件 V.gitattributes。 该 属性 文 
件 的 前 两 行 和 路 径 Wabc 相 匹配 ， 但 是 因为 属性 文件 .git/info/attributes 已 经 
提供 了 foo 和 bar 的 属性 ， 因 此 第 二 行 对 foo 和 bar 属 性 的 设置 不 起 作用 。 
经 过 这 一 步 ， 文 件 Vabc 获 得 的 属性 为 : 











foo : true 

bar : 未 设置 
baz : false 
merge : filfre 





(3) 然后 沿 工 作 区 的 当前 目录 问 上 遍历 属性 文件 ， 找 到 工作 区 根 
目录 下 的 属性 文件 .gitattributes 进 行 检查 。 因 为 前 面 的 属性 文件 已 经 提供 
了 foo、bar 和 baz 属 性 设置 ， 所 以 文件 Vabc 的 属性 和 上 面 第 2 步 的 结果 一 
样 。 





(4) 因为 将 core.attributesfile 设 置 为 ~/.gitattributes 文 件 ， 因 此 接 下 
来 查找 用 户主 目录 下 的 文件 即 .gitattributes。 该 文件 唯一 的 一 行 匹 配 所 有 
的 文件 ， 因 此 tabc 又 被 附加 了 新 的 属性 值 text=auto。 最 终 ， 文 件 t/abc 的 
属性 如 下 : 





foo : true 


bar : 未 设置 
baz : false 
merge : filfre 
text : auto 





Git 提 供 了 一 个 查看 文件 属性 设置 的 命令 :git check-attr。 针 对 本 例 
用 下 面 的 命令 可 以 查看 到 文件 Vabc 各 个 属性 的 设置 情况 。 





$ git check-attr foo bar baz merge text -- t/abc 
t/abc: foo: set 

t/abc: bar: unspecified 

t/abc: baz: unset 

t/abc: merge: filfre 

t/abc: text: auto 





41.1.3 ”常用 属性 介绍 


1.text 


属性 text 用 于 显 式 地 指定 文件 的 类 型 ， 二进制 (-text〉 、 文 本 文件 
(text) 或 是 开局 文件 类 型 的 智能 判别 〈text=auto) 。 对 于 文本 文件 ， 
Git 会 对 其 进行 换行 符 转 换 。 本 篇 第 40 章 “40.3 换 行 符 问题 * 中 己 经 详细 介 
绍 了 属性 text 的 用 法 ， 并 且 在 本 章 “41.1.1 属 性 定义 ”的 示例 中 对 属性 text 
的 取 值 做 了 总 结 ， 在 此 不 再 袭 述 。 


在 “40.3 换 行 符 问题 ”一 节 中 ， 我 们 还 知道 可 以 通过 在 Git 配 置 文件 中 
设置 core.autocrlf 配 置 变量 ， 来 开启 Git 对 文件 类 型 的 智能 判别 ， 并 对 文 
本 文件 开启 换行 符 转 换 。 那 么 Git 的 配置 变量 core.autocrlf 和 属性 text 有 什 


么 异同 呢 ? 





将 Git 的 配置 变量 core.autocrlf 设 置 为 true 或 input， 相 当 于 设置 了 属性 
text=auto。 但 是 Git 配 置 文件 中 的 配置 变量 只 能 在 本 地 进行 设置 并 且 只 对 
本 地 版 本 库 有 效 ， 不 能 通过 共享 版 本 库 传 递 到 其 他 用 户 的 本 地 版 本 库 
中 ， 因 而 core.autocrlf 开 启 的 换行 符 转换 不 能 跟 其 他 用 户 共享 ， 或 者 说 不 
能 将 换行 符 转换 策略 设置 为 整个 项 目 ( 版 本 库 ) 的 强制 规范 。 属 性 文件 
则 不 同 ， 可 以 被 检 入 到 版 本 库 中 并 通过 共享 版 本 库 传递 给 其 他 用 户 ， 
此 可 以 通过 在 检 入 的 .gitattributes 文 件 中 设置 text 属 性 ， 或 者 干脆 设置 
text=auto 属 性 ， 强 制 同一 项 目的 所 有 用 户 在 提交 文本 文件 时 都 要 规范 换 


行 符 。 

















建议 所 有 可 能 要 进行 路 平台 开发 的 项 目 都 在 项 目 根 目 录 中 检 入 一 
个 .gitattributes 文 件 ， 根 据 文件 扩展 名 设置 文件 的 text 属 性 ， 或 者 设置 即 


将 介绍 的 eol 属性 。 





2.e0] 


属性 eol 用 于 设 定 文本 文件 的 换行 符 格 式 。 对 于 设置 了 eol 属性 的 文 
件 ， 如 果 没 有 设 定 text 属 性 时 ， 默 认 会 设置 text 属 性 为 tue。 属 性 eol 的 取 
值 如 下 : 





* eol=crlf 


当 文 件 检 入 版 本 库 时 ，blob 对 象 使 用 LF 作为 换行 符 。 当 检 出 到 工作 
区 时 ， 使 用 CRLF 作 为 换行 符 。 


* eol=]1f 


当 文 件 检 入 版 本 库 时 ，blob 对 象 使 用 LF 作为 换行 符 ， 检 出 的 时 候 工 
作 区 的 文件 也 使 用 LE 作为 换行 符 。 


除了 通过 属性 设 定 换行 符 格式 外 ， 还 可 以 在 Git 的 配置 文件 中 通过 
core.eol 配 置 变量 来 设 定 。 两 者 的 区 别 在 于 配置 文件 中 的 core.eol 配 置 变 
量 设置 的 换行 人 符 是 一 个 默认 值 ， 没 有 通过 eol 属 性 指定 换行 符 格式 的 文 
本 文件 会 采用 core.eol 的 设置 。 变 量 core.eol 的 值 可 以 设 定 为 f、crlf 和 
native。 默认 core.eol 的 取 值 为 native， 即 采用 操作 系统 标准 的 换行 符 格 





起 





下 面 的 示例 通过 属性 文件 设置 文件 的 换行 符 格 式 。 


* ,vcproj eol=cri1f 
*,Sh eol=1f 





扩展 名 为 .vcproj 的 文件 使 用 CRLF 作 为 换行 符 ， 而 扩展 名 为 .sh 的 文 
件 则 使 用 LF 作为 换行 符 。 在 版 本 库 中 检 入 类 似 的 属性 文件 ， 会 使 得 Git 
客户 端 无 论 在 什么 操作 系统 中 都 能 够 在 工作 区 检 出 一 致 的 换行 符 格 式 ， 
这 样 无 论 是 在 Windows 上 还 是 在 Linux 上 使 用 git archive 命 令 将 工作 区 文 
件 打 包 ， 导 出 的 文件 都 会 保持 正确 的 换行 符 格式 。 


3.ident 





属性 ident 开 启 文 本 文件 中 的 关键 字 扩 展 ， 即 关键 字 $Id$ 的 自动 扩 
展 。 当 检 出 到 工作 区 时 ，$Id$ 目 动 扩展 为 $Id:， 后 面 紧 接着 40 位 SHA1 哈 
希 值 ( 相 应 blob 对 象 的 哈 希 值 )， 然 后 以 一 个 $ 字 符 结 尾 。 当 文件 检 入 
时 ， 要 把 内 容 中 出 现 的 以 $Id: 开 始 ， 以 $ 结 束 的 内 容 蔡 换 为 $Id$ 再 保存 到 
blob 对 象 中 。 








这 个 功能 可 以 说 是 对 CVS 相 应 功能 的 致敬 。 自 动 扩展 的 内 容 使 用 的 
是 blob 的 哈 希 值 而 非 提 交 本 吴 的 哈 希 值 ， 因 此 并 无 太 大 的 实际 意义 ， 不 
建议 使 用 。 如 果 和 希望 在 文本 文件 中 扩展 出 提交 者 姓名 、 提 交 ID 等 更 有 实 
际 意义 的 内 容 ， 可 以 参照 后 面 介绍 的 属性 export-subst。 





4.filter 


属性 filter 为 文件 设置 一 个 目 定 义 转换 过 滤器 ， 以 便 文 件 在 检 入 版 本 
库 及 检 出 到 工作 区 时 进行 相应 的 转换 。 定 义 转换 过 滤器 通过 Git 配 置 文 
件 来 完成 ， 因 此 这 个 属性 应 该 只 在 本 地 进行 设置 ， 而 不 要 也 不 能 通过 检 
入 到 版 本 库 中 的 .gitattributes 文 件 来 传递 。 








例如 下 面 的 属性 文件 设置 了 所 有 的 C 语 言 源 文件 在 栓 入 和 检 出 的 时 
候 使 用 名 为 indent 的 代码 格式 化 过 滤 喜 


SG filter=indent 


然后 还 过 Git 配 置 文件 设 定 indent 过 滤器 ， 示 例如 下 : 





[filter "indent"] 
clean = indent 
smudge = cat 


定义 过 滤器 只 要 设置 两 条 命令 ， 一 条 是 名 为 clean 的 配置 设 定 的 的 命 
令 ， 用 于 在 文件 检 入 时 执行 ， 另 外 一 条 是 名 为 smudge 的 配置 设 定 的 命 
令 ， 用 于 将 文件 检 出 到 工作 区 。 对 于 本 例 ， 在 代码 检 入 时 执行 mdent 命 
令 对 代码 格式 化 后 ， 再 保存 到 版 本 库 中 。 妆 检 出 到 工作 区 时 ， 执 行 cat 命 
令 实 际 上 相当 于 直接 将 blob 对 象 复制 到 工作 区 。 





5.diff 





和 前 面 介绍 的 属性 不 同 ， 属 性 diff 不 会 对 文件 检 入 检 出 造成 影响 ， 
而 只 是 在 查看 文件 历史 变更 时 起 作用 。 属 性 diff 可 以 取 值 如 下 : 

-diff 

进行 版 本 间 的 差异 比较 时 ， 以 文本 方式 进行 比较 ， 即 使 文件 看 起 来 
像 是 二 进 制 文 件 〈 包 含 NULL 字 符 ) ， 或 者 被 设置 为 二 进 制 文件 〈- 
text) 。 

* -diff 

不 以 文本 方式 进行 差异 比较 ， 而 以 二 进 制 方式 进行 比较 。 默 认 二 进 
制 文件 不 进行 差异 比较 ， 因 此 包含 -diff 属 性 设置 的 文件 在 差异 比较 时 不 
显示 内 容 上 的 差异 。 对 于 有 些 文本 文件 (如 postscript 文 件 ) 进行 差异 比 
较 没 有 意义 ， 可 以 对 其 设置 -diff 必 性， 避免 在 显示 提交 版 本 间 的 差异 时 
造成 干扰 。 








“| diff 





不 设置 difft 属 性 ， 相 当 于 在 执行 送 民 比较 时 要 对 文件 内 容 进行 智能 
判别 ， 如 果 文 件 看 起 来 像 是 文本 文件 ， 则 显示 文本 格式 的 差 寞 比较 。 











* diff=<driver> 


设 定 一 个 外 部 的 驱动 用 于 文件 的 差异 比较 。 例 如 对 于 Word 文 档 的 


差异 比较 就 可 以 通过 这 种 方式 进行 配置 。 





Word 文 档 属于 二 进 制 文件 ， 默 认 不 显示 差异 比较 。 在 Linux 上 有 一 
个 名 为 antiword 的 应 用 软件 可 以 将 Word 文 档 转 换 为 文本 文件 显示 ， 借 助 
该 软件 就 可 以 实现 在 Linux (包括 Mac OS X) 上 显示 Word 文 件 版 本 间 的 


差异 。 


下 面 的 Git 配 置 就 定义 了 一 个 名 为 antiword 的 适用 于 Word 差 异 比 较 的 
驱动 : 





[diff "antiword"] 
textconv=antiword 





其 中 textconv 属 性 用 于 设 定 一 个 文件 转换 命令 行 ， 这 里 设置 为 
antiword， 用 于 将 Word 文 档 转 换 为 纯 文本 。 


然后 还 需要 设置 属性 ， 修 改版 本 库 下 的 .gitinfo/attributes 文 件 束 可 以 
了 ， 新 增 的 属性 设置 如 下 : 





*.doc diff=antiword 








关于 更 多 的 差异 比较 的 外 部 驱动 的 设置 ， 可 以 执行 git help--web 
attributes 来 参见 相关 的 帮助 。 


6.merge 


属性 merge 用 于 为 文件 设置 指定 的 合并 策略 ， 受 影响 的 Git 命 令 有 : 
git merge、 git revert 和 git cherry-pick 等 。 属 性 merge 可 以 取 值 如 下 : 


* merge 
使 用 内 置 的 三 向 合并 策略 。 


” -nertee 





将 当前 分 支 的 文件 版 本 设置 为 暂时 的 合并 结果 ， 并 且 声 明 合 并 发 生 
了 冲突 ， 这 实际 上 是 二 进 制 文件 默认 的 合并 方式 。 可 以 对 文本 文件 设置 
该 属性 ， 使 得 在 合并 时 的 行为 类 似 于 二 进 制 文 件 。 


* | merge 





和 定义 了 merge 属 性 的 效果 类 似 ， 使 用 内 置 的 三 回合 并 策略 。 然 而 
当 通 过 Git 配 置 文件 的 merge.default 配 置 变量 设置 了 合并 策略 后 ， 如 果 没 
有 为 文件 设置 merge 属 性 ， 则 使 用 merge.default 设 定 的 策略 。 








* merge=<drivert> 





使 用 指定 的 合并 驱动 执行 三 回 文件 合并 。 了 驱动 可 以 是 内 置 的 三 个 豫 
动 ， 也 可 以 是 用 户 通 过 Git 配 置 文件 自 定 义 的 驱动 。 





下 面 重点 说 一 说 通过 枚 举 值 来 指定 在 合并 时 使 用 的 内 置 驱动 和 自 定 
义 驱动 。 先 来 看 看 Git 提 供 的 三 个 内 置 驱动 : 





* Merge=text 





默认 文本 文件 在 进行 三 癌 合 并 时 使 用 的 驱动 。 会 在 合并 后 的 文本 文 
件 中 用 特殊 的 标识 <<<<<<<、======= 和 >>>>>>> 来 标记 冲突 的 内 容 。 


* merge=binary 








默认 二 进 制 文件 在 进行 三 回合 并 时 使 用 的 驱动 。 会 在 工作 区 中 保持 
当前 分 文中 的 版 本 不 变 ， 但 是 会 通过 在 三 个 暂 存 区 中 进行 冲突 标识 ， 使 
得 文件 处 于 冲突 状态 。 


* merge=union 





在 文本 文件 进行 三 回合 并 的 过 程 中 ， 不 使 用 冲突 标识 符 来 标记 冲 
突 ， 而 是 将 冲突 双方 的 内 容 简 单 地 罗列 在 文件 中 。 用 户 应 该 对 合并 后 的 
文件 进行 检查 。 请 愤 用 此 合并 驱动 。 





用 户 还 可 以 自 定义 驱动 。 例 如 Topgit 就 使 用 自 定义 合并 驱动 的 方式 
来 控制 两 个 Topgit 管 理 文件 .topmsg 和 .topdeps 的 合并 行为 。 


Topgit 会 在 版 本 库 的 配置 文件 .git/info/config 中 添加 下 和 面 的 设置 来 定 
义 一 个 名 为 ours 的 合并 驱动 。 注 意 不 要 将 此 ours 驱 动 和 本 书 第 3 篇 第 16 


章 “16.6 合 并 策略 ”一 节 中 介绍 的 ours 合 并 策略 和 弄 混 消 。 





[merge "ours"] 
name = \"always keep ours\" merge driver 
driver = touch %A 


定义 的 合并 驱动 的 名 称 由 merge.*.name 给 出 ， 合 并 时 执行 的 命令 则 
由 配置 merge.*.driver 给 出 。 本 例 中 使 用 了 命令 touch%A， 含 义 为 对 当前 
分 文中 的 文件 进行 简单 的 触 碰 《〈 更 新 文件 时 间 戳 ) ， 亦 即 合并 冲突 时 采 
用 本 地 版 本 ， 于 莽 其 他 版 本 。 





Topgit 还 会 在 版 本 库 .git/info/attributes 属 性 文件 中 包含 下 面 的 属性 设 
置 : 


.topmsg merge=ours 
.topdeps merge=ours 


上 述 设置 的 食 义 为 在 过 到 合并 冲突 时 ， 对 这 两 个 Topgit 管 理 文件 采 
用 在 Git 配 置 文件 中 设 定 的 ours 合 并 驱动 。Topgit 之 所 以 要 这 么 实现 是 因 
为 不 同 特性 分 文 的 管理 文件 之 间 并 无 关联 ， 也 不 需要 合并 ， 在 遇 到 冲突 
时 只 使 用 自己 的 版 本 即 可 。 这 对 于 要 经 常 执行 变 基 和 分 文 合并 的 Topgit 
来 说 ， 设 置 这 个 策略 可 以 简化 管理 ， 但 是 这 个 合并 设置 在 特定 情况 下 也 
存在 不 合理 之 处 。 例 如 两 个 用 户 工 作 在 同一 分 文 上 ， 同 时 更 改 了 .topmsg 
文件 以 修改 特性 分 文 的 描述 ， 在 合并 时 会 覆盖 对 方 的 修改 ， 这 显然 是 不 
好 的 行为 。 但 是 权衡 利 次 ， 还 是 如 此 实现 最 好 。 








7.whitespace 








Git 可 以 对 文本 文件 中 空白 字符 的 使 用 是 否 规范 做 出 检查 ， 在 进行 
文件 差异 比较 时 ， 将 使 用 不 当 的 空白 字符 用 红色 进行 标记 《开局 





color.diff.whitespace ! ”1 ) 。 也 可 以 在 执行 git apply 时 通过 参数 -- 


whitespace=error 防 止 错误 的 空白 字符 应 用 到 提交 中 。 








Git 默 认 开 局 对 下 面 三 类 错误 空白 字符 的 检查 。 


* blank-at-eol 


在 行 尾 出 现 的 空白 字符 (换行 符 之 前 〉 被 视 为 误 用 。 


* space-before-tab 


在 行 首 缩 进 中 出 现在 TAB 字符 前 面 的 空白 字符 视 为 误 用 。 


* blank-at-eof 








在 文件 末尾 的 空白 行 视 为 误 用 。 





Git 还 文 持 对 更 多 空白 字符 的 误 用 做 出 检测 ， 包 括 : 


. Indent-with-non-tab 


用 8 个 或 更 多 的 空格 进行 缩 进 视 为 误 用 。 


”tab-in-indent 


在 行 首 的 缩 进 中 使 用 TAB 字符 视 为 误 用 。 显 然 这 个 设置 和 上 面 的 


indent-with-non-tab 互 斥 。 


* trailing-space 
相当 于 同时 启用 blank-at-eol 和 blank-at-eof。 
* cr-at-eol 


将 行 尾 的 CR〔 回 车 ) 字符 视 为 换行 符 的 一 部 分 。 也 就 是 说 ， 在 行 
尾 前 出 现 的 CR 字符 不 会 引起 trailing-space 报 错 。 


tabwidth 三 <h> 
设置 一 个 TAB 字符 相当 于 几 个 空格 ， 默 认为 8 个 。 


可 以 通过 Git 配 置 文件 中 的 core.whitespace 配 置 变量 ， 设 置 开 启 更 多 
的 空白 字符 检查 ， 将 要 开启 的 空白 字符 检查 项 用 逗号 分 开 即 可 。 





如 果 和 希望 对 特定 路 径 进 行 空 白字 符 检 查 ， 则 可 以 通过 属性 
whitespace 进 行 设置 。 属 性 whitespace 可 以 有 如 下 设置 : 


”Whitespace 





开局 所 有 的 空白 字符 误 用 检查 。 


* -whitespace 


不 对 空白 字符 进行 误 用 检 碍 。 


* | whitespace 
使 用 core.whitespace 配 置 变量 的 设置 进行 空白 字符 误 用 检查 。 
* whitespace=... 


} 隔 各 个 空白 字符 检查 项 。 


闫 | 
由 
Ne 


和 core.whitespace 的 语法 一 样 ， 用 远 
8.export-ignore 

设置 了 该 属性 的 文件 和 目录 在 执行 git archive 时 不 予 导 出 。 
9.export-subst 


如 果 为 文件 设置 了 属性 export-subst， 则 在 使 用 git archive 导 出 项 目 文 


件 时 ， 会 展开 相应 文件 内 容 中 的 占 位 人 符 ， 然 后 再 添加 到 归档 中 。 注 意 如 
果 在 使 用 git archive 导 出 时 使 用 树 ID， 而 没有 使 用 提交 或 里 程 碑 ， 则 不 
会 展开 占 位 符 


占 位 符 的 格式 为 $Format:PLACEHOLDERS$， 其 中 


PLACEHOLDERS 使 用 git log--pretty=format: 相 同 的 参数 〈 有 具体 请 参见 git 
help log 显 示 的 帮助 页 面 ) 。 例 如 : $Format:%H$ 将 展开 为 提交 的 哈 希 
值 ，$Format:%an$ 将 展开 为 提交 者 姓名 。 


10.delta 


如 果 设 置 属性 delta 为 false， 则 不 对 该 路 径 指 向 的 blob 文 件 执行 Delta 


11.encoding 


设置 文件 所 使 用 的 字符 集 ， 以 便 使 用 GUI 工具 〈 如 gitk 和 git-gui) 时 
能 够 正确 显示 文件 内 容 。 基 于 性 能 上 的 考虑 ，gitk 默 认 不 检查 该 属性 ， 
除非 通过 gitk 的 偏好 设置 启用 “Support per-file encodings”。 





如 果 没 有 为 文件 设置 encoding 属 性 ， 则 使 用 git.encoding 配 置 变 量 。 


12.binary 





属性 binary 严 格 来 说 是 一 个 宏 ， 相 当 于 -text-dif。 即 禁止 换行 符 转 
换 ， 以 及 禁止 以 文本 方式 显示 文件 差异 。 











用 户 也 可 以 自 定义 宏 。 自 定义 宏 只 能 在 工作 区 根 目 录 中 
的 .gitattributes 文 件 中 添加 ， 以 内 置 的 binary 宏 为 例 ， 相 当 于 在 属性 文件 
中 进行 了 如 下 的 设置 : 





[attrjbinary -diff -text 





[1 随 着 Git 安 装 方式 的 不 同 ， 这 个 文件 的 位 置 也 可 能 不 同 。 
[2 如 果 设 置 colof.ui 配 置 变量 为 tue， 则 针对 所 有 Git 命 令 开 居 颜色 输出 。 


41.2 ”钩子 和 模板 
41.21 妆 届 鸭子 


Git 的 钧 子 脚本 位 于 版 本 库 的 .gibhooks 目 录 下 ， 当 Git 执 行 特 定 操作 
时 会 调用 特定 的 钩子 脚本 。 当 版 本 库 通 过 git init 或 git clone 创 建 时 ， 会 
在 .git/hooks 目 录 下 创建 示例 脚本 ， 用 户 可 以 参照 示例 脚本 的 写法 开发 适 
合 的 钩子 脚本 。 





钓 子 脚本 要 设置 为 可 运行 ， 并 使 用 特定 的 名 称 。Git 提 供 的 示例 肢 
本 都 带 有 .sample 扩 展 名 ， 是 为 了 防止 被 意外 运行 。 如 果 需 要 启用 相应 的 
钓 子 脚本 ， 需 要 对 其 重 命名 (去 掉 .sample 扩 展 名 ) 。 下 面 分 别 对 可 用 的 
钩子 脚本 逐一 进行 介绍 。 





1.applypatch-msg 


该 钩子 脚本 由 git am 命令 调用 。 在 调用 时 问 该 脚本 传递 一 个 参数 ， 
即 保 存 有 提交 说 明 的 文件 的 文件 名 。 如 果 该 脚本 运行 失败 〈 返 回 非 零 
值 ) ， 则 git am 命令 在 应 用 该 补丁 之 前 终止 。 








这 个 钩子 脚本 可 以 修改 文件 中 保存 的 提交 说 明 ， 以 便 规 范 提 交 说 明 
以 符合 项 目的 标准 (如 果 有 的 话 )。 如 果 提 交 说 明 不 符合 项 目标 准 ， 脚 


本 直接 以 非 零 值 退出 ， 则 拒绝 提交 。 


Git 提 供 的 示例 脚本 applypatch-msg.sample 只 是 简单 地 调用 commit- 
msg 钧 子 脚本 (如 果 存 在 的 话 ) 。 这 样 通过 git am 命令 应 用 补丁 和 执行 
git commit 一 样 ， 都 会 执行 commit-msg 脚 本 ， 因 此 如 需 定制 ， 请 更 改 


commit-msg 脚 本 。 
2.pre-applypatch 


该 钩子 脚本 由 git am 命令 调用 。 该 脚本 没有 参数 ， 在 补丁 应 用 后 但 
尚未 提交 前 运行 。 如 果 该 脚本 运行 失败 (返回 非 零 值 )， 则 不 会 提交 已 
经 应 用 了 补丁 的 工作 区 文件 。 





这 个 脚本 可 以 用 于 对 应 用 补丁 后 的 工作 区 进行 测试 ， 如 果 测 试 没 有 
通过 则 拒绝 提交 。 

Git 提 供 的 示例 脚本 pre-applypatch.sample 只 是 简单 地 调用 pre-commit 
钩子 脚本 (如 果 存 在 的 话 ) 。 这 样 通 过 git am 命 令 应 用 补丁 和 执行 git 


commit 一 样 都 会 执行 pre-commit 脚 本 ， 因 此 如 需 定制 ， 请 更 改 pre- 
commit 脚 本 。 


3.post-applypatch 


该 钩子 脚本 由 git am 命令 调用 。 该 脚本 没有 参数 ， 在 补丁 应 用 并 且 
提交 之 后 运行 ， 因 此 该 钩子 脚本 不 会 影响 git am 的 运行 结果 ， 可 以 用 于 


发 送 通知 。 
4.pre-commit 


该 钩子 脚本 由 git commit 命 令 调 用 。 可 以 通过 传递 --no-verify 参 数 而 
禁用 。 该 脚本 在 获取 提交 说 明之 前 运行 。 如 有 果 该 脚本 运行 失败 (返回 非 
零 值 ) ，Git 提 交 就 被 终止。 





该 脚本 主要 用 于 对 提交 数据 的 检查 ， 例 如 对 文件 名 进行 检查 (是 否 
使 用 了 中 文 文件 名 〉， 或 者 对 文件 内 容 进行 检查 (是 否 使 用 了 不 规范 的 


Ts 


Git 提 供 的 示例 脚本 pre-commit.sample 禁 止 提交 在 路 径 中 使 用 非 
ASCI 字 符 〈 如 中 文字 符 ) 的 文件 。 如 果 确 有 使 用 的 必要 ， 可 以 在 Git 配 
置 文件 中 设置 配置 变量 hooks.allownonascii 为 true 以 允许 在 文件 名 中 使 用 
非 ASCII 字 符 。Git 提 供 的 该 示例 脚本 也 对 不 规范 的 空白 字符 进行 检查 ， 
如 果 发 现 则 终止 提交 。 





Topgit 为 所 管理 的 版 本 库 设置 了 自己 的 pre-commit 脚 本 ， 检 查 工 作 
的 Topgit 特 性 分 文 是 否 正确 地 设置 了 Topgit 的 两 个 管理 文件 .topdeps 
和 .topmsg， 以 及 定义 的 分 文 依赖 是 售 存 在 着 重复 依赖 和 循环 依赖 等 。 





5.prepare-commit-msg 


该 钩子 脚本 由 git commit 命 令 调 用 ， 在 默认 的 提交 信息 准备 完成 后 





但 编辑 器 尚未 局 动 之 前 运行 。 


该 脚本 有 1~3 个 参数 。 第 一 个 参数 是 包含 提交 说 明 的 文件 的 文件 
名 。 第 二 个 参数 是 提交 说 明 的 来 源 ， 可 以 是 message《〈 由 -mm 或 -F 参 数 提 
供 ) ， 可 以 是 template (如 果 使 用 了 -t 参 数 或 由 commit.template 配 置 变 量 
提供 ) ， 或 者 是 merge 如果 提交 是 一 个 合并 或 存在 .giWMERGE_MSG 
文件 ) ， 或 者 是 squash 〈 如 果 存 在 .giVSQUASH MSG 文件 ) ， 或 者 是 
commit 并 跟着 一 个 提交 SHA1 哈 希 值 《如 有 果 使 用 -c、-C 或 --amend 参 
数 ) 。 








如 果 该 脚本 运行 失败 《返回 非 零 值 ) ，Git 提 区 就 被 终止 。 


该 脚本 用 于 对 提交 说 明 进 行 编辑 ， 并 且 该 脚本 不 会 因为 --no-verify 
参数 被 蔡 用 。 


Git 提 供 的 示例 脚本 prepare-commit-msg.sample 可 以 用 于 同 提 交 说 明 


中 舱 入 提交 者 的 签名 ， 或 者 将 来 和 目 merge 的 提交 说 明 中 含 
有 “Conflicts:” 的 行 去 邱 。 


6.commit-msg 


该 钩子 脚本 由 git commit 命 令 调 用 ， 可 以 通过 传递 --no-verify 参 数 而 
禁用 。 该 脚本 有 一 个 参数 ， 即 包含 有 提交 说 明 的 文件 的 文件 名 。 如 果 该 
脚本 运行 失败 (返回 非 零 值 )，Git 提 交 被 终止 。 





该 脚本 可 以 直接 修改 提交 说 明 ， 可 以 用 于 规范 提交 说 明 以 符合 项 目 
的 标准 (如 果 有 的 话 ) 。 如 果 提 交 说 明 不 符合 标准 ， 可 以 拒绝 提交 。 


Git 提 供 的 示例 脚本 commit-msg.sample 检 查 提 交 说 明 中 出 现 的 相同 
的 含 “Signed-off-by” 的 行 ， 如 果 发 现 重 复 签名 即 报错 并 终止 提交 。 


Gerrit 服 务 器 需要 每 一 个 辐 其 进行 推送 的 Git 版 本 库 在 本 地 使 用 Gerrit 
提供 的 commit-msg 钓 子 脚本 ， 以 便 在 创建 的 提交 中 包含 形 如 “Change- 
Id:I...” 的 变更 集 标签 。 


7.post-commit 








该 钩子 脚本 由 git commit 命 令 调 用 ， 不 带 参 数 运行 ， 在 提交 完成 之 
后 被 触发 执行 。 


该 钩子 脚本 不 会 影响 git commit 的 运行 结果 ， 可 以 用 于 发 送 通知 。 
8.pre-rebase 
该 钩子 脚本 由 git rebase 命 令 调用 ， 用 于 防止 茶 个 分 文 参与 变 基 。 


Git 提 供 的 示例 脚本 pre-rebase.sample 是 针对 Git 项 目 自身 的 情况 而 开 
发 的 ， 当 一 个 功能 分 支 已 经 合并 到 next 分 支 后 ， 禁 止 该 分 支 进行 变 基 操 
{Es 


9.post-checkout 





该 钩子 脚本 由 git checkout 命 令 调用 ， 在 完成 工作 区 更 新 之 后 触发 执 
行 。 该 钩子 脚本 有 三 个 参数 ， 分 别 是 : 之 前 的 HEAD 所 指向 的 引用 、 新 
的 HEAD 所 指向 的 引用 (可 能 和 前 一 个 一 样 也 可 能 不 一 样 》， 以 及 一 个 
用 于 表示 此 次 检 出 是 否 是 分 支 检 出 的 标识 (分 支 检 出 为 1， 文 件 检 出 是 


0) 。 该 钩子 脚本 不 会 影响 git checkout 命 令 的 运行 结 





除了 由 git checkout 命 令 调 用 外 ， 该 钩子 脚本 也 在 git clone 命 令 执行 
后 被 触 肥 执行， 除非 在 元 隆 时 使 用 了 茶 止 检 出 的 --no-checkout (-n) 参 
数 。 在 由 git clone 调 用 时 ， 第 一 个 参数 给 出 的 引用 是 空 引 用 ， 则 第 二 个 
和 第 三 个 参数 都 为 1。 








这 个 钩子 一 般 用 于 版 本 库 的 有 效 性 检查 ， 目 动 亚 示 和 前 一 个 HEAD 
的 差异 ， 或 者 设置 工作 区 属性 。 

10.post-merge 

该 钩子 脚本 由 git merge 命 令 调用 ， 当 在 本 地 版 本 库 完 成 git pull 操 作 
后 触发 执行 。 该 钧 子 脚 本 有 一 个 参数 ， 标 识 合并 是 否 是 一 个 压缩 合并 。 
该 钧 子 脚 本 不 会 影响 git merge 命 令 的 运行 结果 。 如 果 合 并 因为 冲突 而 失 
败 ， 则 该 脚本 不 会 执行 。 








该 钩子 脚本 可 以 与 pre-commit 钧 子 脚 本 一 起 实现 对 工作 区 目录 树 属 
性 (如 权限 / 属 主 /ACL 等 ) 的 保存 和 恢复 。 参 见 Git 源 码 文 件 


contrib/hooks/setgitperms.perl 中 的 示例 。 


11.pre-receive 


该 钧 子 脚本 由 远程 版 本 库 的 git receive-pack 命 令 调 用 。 当 从 本 地 版 
本 库 完 成 一 个 推送 之 后 ， 在 远程 服务 器 上 开始 批量 更 新 引用 之 前 ， 该 钓 
子 脚 本 被 触发 执行 。 该 钩子 脚本 的 退出 状态 决定 了 更 新 引用 的 成 功 与 


不 
器 o 





该 钩子 脚本 在 接收 (receive) 操作 中 只 执行 一 次 。 传 递 参数 不 通过 
命令 行 ， 而 是 通过 标准 输入 进行 传递 。 通 过 标准 输入 传递 的 每 一 行 的 语 
法 格式 为 : 


<old-value> <new-value> <ref-name> 


<old-value> 是 引用 更 新 前 的 老 的 对 象 ID，<new-value> 是 引用 即将 
更 新 到 的 新 的 对 象 ID，<ref-name> 是 引用 的 全 名 。 当 创建 一 个 新 引用 


时 ，<old-value> 是 40 个 0。 





如 果 该 钩子 脚本 以 非 零 值 退出 ， 一 个 引用 也 不 会 更 新 。 如 条 该 脚本 
正常 退出 ， 每 一 个 单独 的 引用 的 更 新 仍 有 可 能 被 update 钓 子 所 阻止 。 


标准 输出 和 标准 错误 部 重 定 同 到 在 男 外 一 端 执行 的 git send-pack 
上 ， 上 所 以 可 以 直接 通过 echo 命 令 向 用 户 传递 信息 。 


12.Update 


该 钩子 脚本 由 远程 版 本 库 的 git receive-pack 命 令 调 用 。 当 从 本 地 版 
本 库 完 成 一 个 推送 之 后 ， 在 远程 服务 器 上 更 新 引用 时 ， 该 钩子 脚本 被 触 
发 执行 。 该 钩子 脚本 的 退出 状态 决定 了 更 新 引用 的 成 功 与 合 。 











该 钩子 脚本 在 每 一 个 引用 更 新 的 时 候 都 会 执行 一 次 。 该 脚本 有 三 个 


参数 。 
` 参数 1: 要 更 新 的 引用 的 名 称 。 
. 参数 2: 引用 中 保存 的 旧 对 象 名 称 。 
- 参数 3: 将 要 保存 到 引用 中 的 新 对 象 名 称 。 


正常 退出 (返回 0〉 则 允许 更 新 该 引用 ， 而 以 非 零 值 退出 则 禁 J 上 git- 
receive-pack 更 新 该 引用 。 


该 钩子 脚本 可 以 用 于 防止 菜 些 引 用 被 强制 更 新 ， 因 为 该 脚本 可 以 通 
过 检查 新 旧 引 用 对 象 是 否 存在 继承 关系 ， 从 而 提供 更 为 细致 的 “ 非 快 进 
式 推送 ”的 授权 。 





该 钩子 脚本 也 可 以 用 于 记录 〈 如 用 邮件 ) 引用 变更 历史 old..new。 
然而 因为 该 脚本 不 知道 完整 的 引用 更 新 ， 所 以 可 能 会 导致 每 一 个 引用 发 
送 一 封 邮件 。 因 此 如 果 要 发 送 通知 邮件 ， 可 能 post-receive 钧 子 脚本 更 为 


适合 。 





另外 ， 该 脚本 可 以 实现 基于 路 径 的 授权 。 





标准 输出 和 标准 错误 都 重 定 同 到 在 男 外 一 端 执行 的 git send-pack 
上 上 ， 所 以 可 以 直接 通过 echo 命 令 同 用 户 传 递 信息 。 


Git 提 供 的 示例 脚本 update.sample 展 示 了 对 多 种 危险 的 Git 操 作 行为 
进行 控制 的 可 行 性 。 


.只 有 将 配置 变量 hooks.allowunannotated 设 置 为 true 才 允许 推送 轻 量 


级 里 程 碑 (不 带 说 明 的 里 程 碑 ) 。 


.只 有 将 配置 变量 hooks.allowdeletebtranch 设 置 为 ttue 才 允许 删除 分 


. 如 果 将 配置 变量 hooks.denycteatebftanch 设 置 为 true 则 不 允许 创建 新 


. 只 有 将 配置 变量 hooks.allowdeletetag 设 置 为 true 才 允许 删除 里 程 
碑 。 


* 只 有 将 配置 变量 hooks.allowmodifytag 设 置 为 true 才 允许 修改 里 程 
碑 。 


相 比 Git 的 示例 脚本 ，Gitolite 服 务 器 为 其 管理 的 版 本 库 设 置 的 update 
钩子 脚本 更 实用 也 更 强大 。Gitolite 实 现 了 用 户 认 证 ， 并 通过 检查 授权 文 





件 ， 实 现 基 于 分 文 和 路 径 的 写 操 作 授权 ， 等 等 。 有 共 体 内 容 请 参见 本 书 第 


5 篇 “第 30 章 Gitolite 服 务 架 设 ” 的 相关 内 容 。 
13.post-receive 


该 钩子 脚本 由 远程 版 本 库 的 git receive-pack 命 令 调 用 。 当 从 本 地 版 
本 库 完 成 一 个 推送 ， 并 且 在 远程 服务 问 上 的 所 有 引用 都 更 新 完毕 后 ， 该 
钩子 脚本 被 触发 执行 。 


该 钩子 脚本 在 接收 〈receive) 操作 中 只 执行 一 次 。 该 脚本 不 通过 命 
令 行 传递 参数 ， 但 是 像 pre-receive 和 钩子 脚本 那样 ， 通 过 标准 输入 以 相同 
格式 获取 信息 。 


该 钩子 脚本 不 会 影响 git-receive-pack 的 结果 ， 因 为 调用 该 脚本 时 工 
作 已 经 完成 














该 钩子 脚本 胜 过 postrupdate 脚 本 之 处 在 于 : 它 可 以 获得 所 有 引用 的 
老 的 和 新 的 值 ， 以 及 引用 的 名 称 。 


标准 输出 和 标准 错误 部 重 定 同 到 在 男 外 一 端 执行 的 git send-pack 
上 上 ， 所 以 可 以 直接 通过 echo 命 令 同 用 户 传 递 信息 。 


Git 提 供 的 示例 脚本 post-receive.sample 引 入 了 contrib/hooks 目 录 下 的 
名 为 post-receive-email 的 示例 脚本 默认 被 注释 ) ， 以 实现 发 送 通知 邮 
件 的 功能 。 


Gitolite 服 务 器 要 对 其 管理 的 Git 版 本 库 设置 post-receive 钓 子 脚 本 ， 
以 实现 当 版 本 库 有 变更 后 将 数据 传输 到 各 个 镜像 版 本 库 。 


14.post-update 


该 钩子 脚本 由 远程 版 本 库 的 git receive-pack 命 令 调 用 。 当 从 本 地 版 
本 库 完 成 一 个 推送 之 后 ， 即 当 所 有 引用 都 更 新 完毕 后 ， 在 远程 服务 器 上 
该 钩子 脚本 被 触发 执行 。 


该 脚本 接收 不 定 长 的 参数 ， 每 个 参数 实际 上 就 是 已 经 成 功 更 新 的 引 
用 名 。 





该 钩子 脚本 不 会 影响 git-receive-pack 的 结果 ， 因 此 主要 用 于 通知 。 


钩子 脚本 post-update 虽 然 能 够 提供 哪些 引用 被 更 新 了 ， 但 是 该 脚本 
不 知道 引用 更 新 前 后 的 对 象 SHA1 哈 希 值 ， 所 以 在 这 个 脚本 中 不 能 记录 
形 如 old..new 的 引用 变更 范围 。 而 钩子 脚本 post-receive 知 道 引用 更 新 前 
后 的 对 象 ID， 因 此 更 适合 于 此 种 场合 。 





标准 输出 和 标准 错误 部 重 定 同 到 在 男 外 一 端 执行 的 git send-pack 
上 上 ， 所 以 可 以 直接 通过 echo 命 令 同 用 户 传 递 信息 。 


Git 提 供 的 示例 脚本 post-update.sample 会 运行 git update-server-info 命 
令 ， 以 更 新 哑 协 议 需 要 的 索引 文件 。 如 果 通 过 哑 协 议 共享 版 本 库 ， 应 该 
启用 该 钓 子 脚本 。 


15.pre-auto-gc 


该 钩子 脚本 由 git gc--auto 命 令 调 用 ， 不 带 参 数 运 行 ， 如 果 以 非 零 值 
退出 会 导致 git gc--auto 被 中 断 。 


16.post-rewrite 


该 钩子 脚本 由 一 些 重 写 提 区 的 命令 调用 ， 如 git commit--amend、git 
rebase， 而 git-filter-branch 当 前 尚未 调用 该 钩子 脚本 。 


该 脚本 的 第 一 个 参数 用 于 判断 调用 来 自 哪 个 命令 ， 当 前 有 amend 和 
rebase 两 个 取 值 ， 也 可 能 将 来 会 传递 其 他 的 更 多 命令 相关 的 参数 。 





该 脚本 通过 标准 输入 接收 一 个 重 写 提 区 列表 ， 每 一 行 输入 的 格式 如 
下 : 





<old-sha1i> <new-shai> [<extra-info>] 





前 两 个 是 旧 的 和 新 的 对 象 SHA1 哈 希 值 。 而 <extra-info> 参 数 是 和 调 
用 命令 相关 的 ， 当 前 该 参数 为 空 。 


41.2.2” ”Git 模板 


当 执 行 git init 或 git clone 创 建 版 本 库 时 ， 会 自动 在 版 本 库 中 创建 钩子 
脚本 .git/hooks/*) 、 忽 略 文件 〈.giUinfo/exclude) 及 其 他 文件 ， 实 际 


上 这 些 文件 均 找 贝 目 模板 目录 。 如 果 需 要 本 地 版 本 库 使 用 定制 的 钩子 脚 
本 等 文件 ， 直 接 在 模板 目录 内 创建 〈 文 件 或 符号 链接 ) 会 事半功倍 。 


Git 按 照 下 列 顺序 第 一 个 确认 的 路 径 即 为 模板 目录 。 


(1) 如 果 执 行 git init 或 git clone 命 令 时 ， 提 供 --template=<DIR> 参 
数 ， 则 使 用 指定 的 目录 作为 模板 目录 。 





(2) 由 环境 变量 $GIT TEMPLATE _ DIR 指定 的 模板 目录 。 


(3) 由 Git 配 置 变 量 init.templatedir 指 定 的 模板 目录 。 





(4) 默认 的 模板 目录 ， 根 据 Git 安 装 路 径 的 不 同 可 能 位 于 不 同 的 目 
录 下 。 可 以 通过 下 面 命令 确认 其 实际 位 置 : 


$ echo $(dirname $(dirname $(git --html-path)))/git-core/templates 
/usr/share/git-core/templates 


如 果 在 执行 版 本 库 初 始 化 时 传递 了 空 的 模板 路 径 ， 则 不 会 在 版 本 库 
中 创建 钩子 脚本 等 文件 。 





$ git init --template= simplegit 
Initialized empty Git repository in /path/to/my/workspace/simplegit/.git/ 








执行 下 面 的 命令 ， 奏 看 新 创建 的 版 本 库 .git 目 录 下 的 文件 。 


$ ls -F simplegit/.git/ 
HEAD config objects/ refs/ 


可 以 看 到 不 使 用 模板 目录 创建 的 版 本 库 下 面 的 文件 少 的 可 怜 。 而 通 
过 对 模板 目录 下 的 文件 的 定制 ， 可 以 使 得 在 建立 的 版 本 库 中 包含 预先 设 
置 好 的 钩子 脚本 、 名 略 文件 、 属 性 文件 甚至 config 配 置 文件 等 。 这 给 对 
服务 器 或 对 版 本 库 操作 有 特殊 要 求 的 项 目 带 来 了 方便 。 





41.3” 稀 朴 检 出 和 浅 克 隆 


41.3.1 稀疏 检 出 


从 1.7.0 版 本 开始 Git 提 供 稀 芷 检 出 的 功能 。 所 谓 黎 玻 检 出 就 是 ， 本 
地 版 本 库 检 出 时 不 检 出 全 部 ， 只 将 指定 的 文件 从 本 地 版 本 库 中 检 出 到 工 
作 区 ， 而 其 他 未 指定 的 文件 则 不 予 检 出 即使 这 些 文 件 存在 于 工作 区 ， 
其 修改 也 会 被 忽略 〉。 





要 想 实 现 稀 下 检 出 的 功能 ， 必 须 同时 设置 core.sparseCheckout 配 置 
变量 ， 并 存在 文件 .giVinfo/sparse-checkout。 即 首先 要 设置 Git 配 置 变量 
core.sparseCheckout 为 tue， 然 后 编辑 .git/info/sparse-checkout 文 件 ， 将 要 
检 出 的 目录 或 文件 的 路 径 写 入 其 中 。 其 中 文件 .giVinfo/sparse-checkout 的 
格式 就 和 .gitignore 文 件 格式 一 样 ， 路 径 可 以 使 用 通配符 。 





稀疏 检 出 是 如 何 实现 的 呢 ? 实 际 上 Git 在 index( 即 暂 存 区 〉 中 为 每 
个 文件 提供 一 个 名 为 skip-worktree 的 标志 位 ， 默 认 这 个 标志 位 处 于 关闭 
状态 。 如 果 开启 该 标志 位 ， 则 无 论 工作 区 对 应 的 文件 存在 与 否 ， 或 者 是 
个 被 修改 ，Git 都 认为 工作 区 该 文件 的 版 本 是 最 新 的 、 无 变化 的 。Git 通 
过 配置 文件 .git/info/sparse-checkout 定 义 一 个 要 检 出 的 目录 和 /或 文件 列 
表 ， 当 前 Git 的 git read-tree 命 令 及 其 他 基于 合并 的 命令 (git merge、git 


checkout 等 ) 能 够 根据 该 配置 文件 更 新 的 index 中 文件 的 skip-worktree 标 
志 位 ， 实 现 版 本 库 文 件 的 稀 跑 检 出 。 


先 在 工作 区 /path/to/my/workspace 中 创建 一 个 示例 版 本 库 sparsel1， 创 
建 后 的 sparsel 版 本 库 中 包含 如 下 内 容 : 





$ 1s -F 
doc1/ doc2/ doc3/ 
$ git ls-files -s -v 


H 100644 ce013625030ba8dba906f756967f9e9ca394464a 0 doci/readme.txt 
H 100644 ce013625030ba8dba906f756967f9e9ca394464a 0 doc2Vreadme .txXt 
H 100644 ce013625030ba8dba906f756967f9e9ca394464a 0 doc3/readme .txXt 





即 版 本 库 sparse1 中 包含 三 个 目录 doc1、doc2 和 doc3。 命 令 git ls-files 
的 -s 参 数 用 于 显示 对 象 的 SHA1 哈 希 值 及 所 处 的 暂 存 区 的 编号 。 而 -v 参 数 
则 显示 工作 区 文件 的 状态 ， 每 一 行 命令 输出 的 第 一 个 字符 即 是 文件 状 
态 : 字母 H 表 示 文 件 已 被 暂 存 ， 如 果 是 字母 S 则 表示 该 文件 skip-worktree 
的 标志 位 已 开启 。 














下 面 我 们 就 来 体验 一 下 黎 玻 检 出 的 功能 。 


(1) 修改 版 本 库 的 Git 配 置 变 量 core.sparseCheckout， 将 其 设置 为 


true。 





$ git config core,SparseCheckout true 





(2) 设置 .git/info/sparse-checkout 的 内 容 ， 如 下 : 





$ printf "doci\ndoc3\n" > .git/info/sparse-checkout 
$ cat .git/info/sparse-checkout 

doc1 

doc3 





(3) 执行 git checkout 命 令 后 ， 会 发 现 工作 区 中 的 doc2 目 录 不 见 
i 





$ git checkout 
$ 1s -F 
doc1/ doc3/ 





(4) 这 时 如 果 用 git 1s-files 命 令 查 看 ， 会 发 现 doc2 目 录 下 的 文件 被 


设置 了 skip-worktree 标 志 。 





$ git ls-files -V 
H doci/readme.txt 
S doc2/readme.txt 
H doc3/readme.txt 





(5) 修改 .git/info/sparse-checkout 的 内 容 ， 如 下 : 





$ printf "doc3\n" > .git/info/sparse-checkout 
$ cat .git/info/sparse-checkout 
doc3 





(6) 执行 git checkout 命 令 后 ， 会 发 现 工作 区 中 的 doc1l 目 录 也 不 见 
二 本 





$ git checkout 
$ 1s -F 
doc3/ 





(7) 这 时 如 果 用 git ls-files 命 令 查 看 ， 会 发 现 doc1 和 doc2 目 录 下 的 
文件 都 被 设置 了 skip-worktree 标 志 。 





$ git ls-files -V 
S doci/readme.txt 
S doc2/readme.txt 
H doc3/readme.txt 





(8) 修改 .git/info/sparse-checkout 的 内 容 ， 使 之 包含 一 个 星 写 ， 即 
在 工作 区 检 出 所 有 的 内 容 。 





$ printf "*\n" > .git/info/sparse-checkout 
$ cat .git/info/sparse-checkout 
* 








(9) 执行 git checkout， 会 发 现 所 有 目录 又 都 回来 了 。 





$ git checkout 
$ ls -F 
doc1/ doc2/ doc3/ 





文件 .git/info/sparse-checkout 的 格式 类 似 于 .gitignore 的 格式 ， 也 支持 
用 感叹 号 实现 反 回 操作。 例如 不 检 出 目录 doc2 下 的 文件 ， 而 检 出 其 他 文 
件 ， 可 以 使 用 下 面 的 语法 (注意 顺序 不 能 写 反 )〉: 





* 
1doc2/ 





注意 如 果 使 用 命令 git checkout--<file>...， 即 不 是 切换 分 支 而 是 用 分 
文中 的 文件 蔡 换 暂 存 区 和 工作 区 ， 则 忽略 skip-worktree 标 志 。 例 如 下 面 





的 操作 中 ， 虽 然 doc2 被 设置 为 不 检 出 ， 但 是 执行 git checkout. 命 令 后 ， 所 
有 的 目录 还 是 都 被 检 出 了 。 








$ git checkout ， 
$ ls -F 

doc1/ doc2/ doc3/ 
$ git ls-files -V 
H doci/readme.txt 
S doc2/readme.txt 
H doc3/readme.txt 








如 果 修 改 doc2 目 录 下 的 文件 ， 或 者 在 doc2 目 录 下 添加 新 文件 ，Git 会 
视而不见 。 





$ echo hello >> doc2/readme.txt 

$ git status 

# On branch master 

nothing to commit (working directory clean) 





若 此 时 通过 取消 core.sparseCheckout 配 置 变 量 的 设置 而 关闭 稀 琉 检 
出 ， 也 不 会 改变 目录 doc2 下 的 文件 的 skip-worktree 标 志 。 这 种 情况 或 者 
通过 git update-index--no-skip-worktree--<file>... 来 更 改 index 中 对 应 文件 的 
skip-worktree 标 志 ， 或 者 重新 启用 稀疏 检 出 更 改 相 应 文件 的 检 出 状态 。 








如 采 在 殉 隆 一 个 版 本 库 时 只 和 希望 检 出 部 分 文件 或 目录 ， 可 以 在 执行 
克隆 操作 的 时 候 使 用 --no-checkout 或 -n 参 数 ， 不 进行 工作 区 文件 的 检 
出 。 例 如 下 面 的 操作 从 前 面 示例 的 sparsel 版 本 库 克 隆 到 sparse2 中 ， 不 进 
行 工 作 区 文件 的 检 出 。 





$ git clone -n Sparse1 Sparse2 
Cloning into sparse2... 


done. 





检 出 完成 后 可 以 发 现 sparse2 的 工作 区 是 空 的 ， 而 且 版 本 库 中 也 不 存 
在 index 文 件 。 如 果 执 行 git status 命 令 会 看 到 所 有 文件 都 被 标识 为 删除 。 





$ cd sparse2 

$ git status -s 

D doci/readme.txt 
D doc2/readme.txt 
D doc3/readme.txt 





如 果 希 望 通 过 黎 芷 检 出 的 功能 ， 只 检 出 其 中 一 个 目录 如 doc2， 可 以 
用 如 下 方法 实现 : 





$ git config core,SparseCcheckout true 
$ printf "doc2\n" > .git/info/sparse-checkout 
$ git checkout 





之 后 看 到 工作 区 中 检 出 了 doc2 目 录 ， 而 其 他 文件 被 设置 了 skip- 


worktree 标 志 。 








$ 1s -F 

doc2/ 

$ git ls-files -V 
S doci/readme.txt 
H doc2/readme.txt 
S doc3/readme.txt 





41.3.2 ”小 克隆 


上 一 节 介 绍 的 稳 玻 检 出 ， 可 以 部 分 检 出 版 本 库 中 的 文件 ， 但 是 版 本 





库 本 身 仍然 包含 所 有 的 文件 和 历史 。 如 果 只 对 一 个 大 的 版 本 库 的 最 近 的 
部 分 历史 提交 感 兴 趣 ， 而 不 想 元 隆 整 个 版 本 库 ， 稀 琉 检 出 是 解决 不 了 这 
个 问题 的 ， 应 采用 本 节 介 绍 的 浅 殉 隆 。 


实现 版 本 库 的 浅 克 隆 非常 简单 ， 只 需要 在 执行 git clone 或 git fetch 操 
作 时 用 --depth<depth> 参 数 设 定 要 获取 的 历史 提交 的 深度 〈<depth> 大 于 
0) ， 就 会 把 源 版 本 库 分 支 上 最 近 的 <depth>+1 个 历史 提交 作为 新 版 本 库 
的 全 部 历史 提交 。 


通过 浅 克 隆 方式 元 隆 出 来 的 版 本 库 ， 每 一 个 提交 的 SHA1 哈 希 值 和 
源 版 本 库 都 相同 ， 包 括 提交 的 根 节点 也 是 如 此 ， 但 是 Git 通 过 特殊 的 实 
现 ， 使 得 浅 克 隆 的 根 节 点 提交 看 起 来 没有 父 提交 。 正 因为 浅 克隆 的 提交 
对 象 的 SHA1 哈 希 值 和 源 版 本 库 一 致 ， 所 以 浅 克 隆 版 本 库 可 以 执行 git 
fetch 或 git pull 从 源 版 本 库 获 取 新 的 提交 。 但 是 浅 克 隆 版 本 库 也 存在 着 很 
多 限制 ， 如 : 





. 不 能 从 浅 克 隆 版 本 库 克 隆 出 新 的 版 本 库 。 


. 其 他 版 本 库 不 能 从 浅 克 隆 版 本 库 中 获取 提交 。 


. 其 他 版 本 库 不 能 推送 提交 到 浅 克 隆 版 本 库 。 


: 不 要 从 浅 克 隆 版 本 库 推送 提交 至 其 他 版 本 库 ， 除 非 确认 推送 的 目 
标 版 本 库 包含 浅 克 隆 版 本 库 中 缺失 的 全 部 历史 提交 ， 和 否则 会 因为 目标 版 


本 库 包 含 不 完整 的 提交 历史 而 导致 版 本 库 无 法 操作 。 


在 浅 克 隆 版 本 库 中 执行 合并 操作 时 ， 如 果 所 合并 的 提交 出 现在 浅 
克隆 版 本 库 的 历史 中 ， 则 可 以 顺利 合并 ， 否则 会 出 现 大 量 的 冲突 ， 就 好 
像 和 无 关 的 历史 进行 合并 一 样 。 





由 于 浅 区 隆 包含 上 述 限制 ， 因 此 浅 死 隆 一 般 用 于 对 远程 版 本 库 的 奉 
看 和 研究 ， 如 果 在 浅 克 隆 版 本 库 中 进行 了 提交 ， 最 好 通过 git format- 
patch 命 令 导 出 为 补丁 文件 再 应 用 到 远程 版 本 库 中 。 


下 面 的 操作 使 用 git done 命 令 创 建 一 个 浅 元 隆 。 注 意 : 源 版 本 库 如 
果 是 本 地 版 本 库 ， 就 要 使 用 file:/ 协 议 ， 知 直接 使 用 本 地 路 径 则 不 会 实现 
浅 元 隆 。 





$ git clone --depth 2 file:///path/to/repos/hello-world.git shallow1 








然后 进入 到 本 地 死 隆 目 录 中 ， 会 看 到 当前 分 文 上 只 有 3 个 提交 。 








$ git log --oneline 

c4acab2 Translate for Chinese. 
683448a Add I18N support. 

d81896e Fix typo: -help to --help. 





得 看 提交 的 根 节 点 d81896e， 会 看 到 该 提交 实际 上 也 包含 父 提 交 。 





$ git cat-file -p HEADAA 

tree f9d7f6boaf6f3fffa74eb995f1d781d3c4876b25 

parent 10765a7ef46981a73d578466669f6e17b73ac7e3 

author User1 <User1lQ@sun.ossxp.com> 1294069736 +0800 
committer user2 <user2@moon.ossxp.com> 1294591238 +0800 


Fix typo: -help to --help. 





而 得 看 该 提交 的 父 提 交 ，Git 会 报错 。 





$ git log 10765a7ef46981a73d578466669f6e17b73ac7e3 
fatal: bad object 10765a7ef46981a73d578466669f6e17b73ac7e3 





对 于 正 第 的 Git 版 本 库 来 说 ， 如 果 对 象 库 中 丢失 一 个 提交 绝对 是 大 
问题 ， 版 本 库 不 可 能 被 正常 使 用 。 而 浅 死 隆之 所 以 看 起 来 一 切 正常 ， 是 
因为 Git 使 用 了 类 似 媒 接 〈 下 一 节 即 将 介绍 ) 的 技术 。 

在 浅 克 隆 版 本 库 中 存在 一 个 文件 .giyshallow， 这 个 文件 中 罗列 了 应 


该 被 视 为 提交 根 节 点 的 提交 SHA1 哈 希 值 。 查 看 这 个 文件 会 看 到 提交 
d81896e 正 在 其 中 : 





$ cat .git/shallow 

b56bb510a947651e4717b356587945151ac32166 
d81896e60673771ef1873b27a33f52df75f70515 
e64f3a216d346669b85807ffcfb23a21f9c5c187 








列 在 .giVshallow 文 件 中 的 提交 会 构建 出 对 应 的 怒 接 提交 ， 使 用 类 似 
嫁接 文件 .gitinfo/grafts 〈 下 节 讨 论 ) 的 机 制 ， 当 Git 访 问 这 些 对 象 时 就 好 
像 这 些 对 象 是 没有 父 提交 的 根 节 点 一 样 。 


41.4 尹 接 和 普 换 


41.4.1 ”提交 嫁接 


提交 尹 接 可 以 实现 在 本 地 版 本 库 上 将 两 条 完全 不 同 的 提交 线 〈 分 
文 ) 退 接 〈 连 接 ) 到 一 起 。 对 于 一 些 在 迁移 版 本 控制 系统 时 过 到 困难 的 
项 目 ， 该 技术 会 非常 有 帮助 。 例 如 Linux kernel 本 身 的 版 本 控制 系统 在 迁 
移 到 Git 上 时 ， 尚 没有 任何 工具 可 以 将 Linux 的 提交 历史 从 旧 的 Bitkeeper 
版 本 控制 系统 中 导出 ， 直 到 后 来 通过 bkcvs 将 Bitkeeper 上 的 Linux 历 史 提 
交 叶 入 到 Git 中 。 如 何 将 新 旧 两 条 开 友 线 连接 到 一 起 昵 ?于 是 束 故 明了 
提交 怒 接 ， 以 实现 新 旧 两 条 开 友 线 的 合并 ， 这 样 Linux 开 发 者 就 可 以 在 
一 个 开发 分 支 中 由 最 新 的 提交 追踪 到 原来 位 于 Bitkeeper 中 的 提交 。 








提交 嫁接 是 通过 在 版 本 库 中 创建 .givinfo/grafts 文 件 来 实现 的 。 该 广 
件 每 一 行 的 格式 为 : 


<commit shai> <parent shai> [<parent shai>]* 


用 空格 分 开 各 个 字段 ， 其 中 第 一 个 字段 是 一 个 提交 的 SHA1I 哈 希 
值 ， 而 后 面 用 空格 分 开 的 其 他 SHA1 哈 希 值 则 作为 该 提交 的 父 提交 。 把 
一 个 提交 线 的 根 节 点 作为 第 一 个 字段 ， 第 二 个 提交 线 的 顶 三 把 作为 第 二 


个 字段 ， 束 实 现 了 两 个 提交 线 的 尹 接 ， 看 起 来 就 像 是 一 条 提交 线 了 。 





在 本 书 第 6 篇 第 35 章 的 “35.4Git 版 本 库 整 理 ” 中 介绍 的 git filter-branch 
命令 在 整理 版 本 库 时 ， 如 果 发 现存 在 .giUinfo/grafts 则 会 在 物理 上 完成 提 
区 的 退 接 ， 实 现 尹 接 的 永久 生效 。 


41.4.2 ”提交 替换 


提交 蔡 换 是 在 1.6.5 或 更 新 版 本 的 Git 中 提供 的 功能 ， 和 提交 嫁接 类 
似 ， 不 过 提交 交换 不 是 用 一 个 提交 来 伪装 成 吃 外 一 个 提交 的 父 提 交 ， 而 
是 直接 丛 换 妨 外 的 提交 ， 在 不 影响 其 他 提交 的 基础 上 实现 对 历史 提交 的 
修改 。 





提交 蔡 换 是 通过 在 特殊 命名 空间 .git/refs/replace/ 下 定义 引用 来 实现 
的 。 引 用 的 名 称 是 要 被 蔡 换 掉 的 提交 SHA1 哈 希 值 ， 而 引用 文件 的 内 容 
《引用 所 指 同 的 提交 ) 束 是 用 于 将 换 的 〈 正 确 的 ) 提交 SHA1 哈 希 值 。 
由 于 提交 做 换 通 过 引用 进行 定义 ， 因 此 可 以 在 不 同 的 版 本 库 之 间 传 递 ， 
而 不 像 提 交 巡 接 只 能 在 本 地 版 本 库 中 使 用 。 














Git 提 供 git replace 命 令 来 管理 提交 人 痊 换 ， 用 法 如 下 : 











用 法 1: git replace [-f] <object> <replacement> 
用 法 2: git replace -d <object>,.， 
用 法 3: git replace -1 [<pattern>] 





























其 中 : 


: 用 法 1 用 于 创建 提交 替换 ， 即 在 .gittefs/teplace 目 录 下 创建 名 为 的 
引用 ， 其 内 容 为 。 如 果 使 用 -{ 和 参数， 还 允许 级 联 替 换 ， 即 用 于 替换 的 提 
交 可 以 是 另外 一 个 已 经 在 .git/refs/replace 中 定义 的 蔡 换 。 


* 用 法 2 用 于 删除 已 经 定义 的 替换 。 
* 用 法 3 显示 已 经 存在 的 提交 替换 。 


提交 蔡 换 可 以 被 大 部 分 Git 命 令 理解 ， 除 了 一 些 针对 被 蔡 换 的 提交 
使 用 --no-replace-objects 参 数 的 命令 。 例 如 : 


当 提交 foo 被 提交 bafr 替 换 后 ， 显示 未 被 替换 前 的 foo 提 交 : 





$ --no- Re objects cat-file commit foo 
.foo 的 内 容 





. 不 使 用 --no-feplace-objects 参 数 ， 则 访问 foo 会 显示 替换 后 的 bafr 提 





$ cat-file commit foo 
.bar 的 内 容 ,.. 





提交 蕉 换 使 用 引用 进行 定义 ， 因 此 可 以 通过 git fetch 和 git push 在 版 
本 库 之 间 传 递 。 但 因为 默认 Git 只 同步 里 程 碑 和 分 文 ， 因 此 需要 在 命令 
中 显 式 地 给 出 提交 蔡 换 的 引用 表达 式 ， 如 : 





$ git fetch origin refs/replace/* 
$ git push origin refs/replace/* 





提交 蔡 换 也 可 以 实现 两 个 分 支 的 嫁接 。 例 如 要 将 分 支 A 嫁 接 到 B 
上 ， 就 相当 于 将 分 支 A 的 根 握 交 <BRANCH _A_ROOT> 的 父 提交 设置 为 
分 支 B 的 最 新 提交 <BRANCH_B_CURRENT>。 可 以 先 创建 一 个 新 提交 


<BRANCH A NEW_ROOT>， 其 父 提交 设置 为 





<BRANCH_B_CURRENT> 而 提交 的 其 他 字段 和 <BRANCH_A_ROOT> 





完全 一 致 。 然 后 设置 提交 替换 ， 用 <BRANCH _A_NEW_ROOT> 蔡 换 
<BRANCH A ROOT> 即 可 。 


可 以 使 用 下 面 的 命令 创建 <BRANCH A _NEW_ROOT>， 注 意 要 用 
实际 值 奉 换 下 面 命令 中 的 <BRANCH_A_ROOT> 和 


<BRANCH_B_CURRENT>。 





$ git cat-file commit <BRANCH_A_ROOT> | 
sed -e "/Atree /a\ 
parent $(git rev-parse <BRANCH_B_ CURRENT>)" | 
git hash-object -t commit -w --stdin 





其 中 git cat-file commit 命 令 用 于 显示 提交 的 原始 信息 ，sed 命 令 用 于 
向 原始 提交 中 插入 一 条 parent SHA1... 的 语句 ， 而 命令 git hash-object 是 一 
个 Git 压 层 命 令 ， 可 以 将 来 自 标准 输入 的 内 容 创 建 为 一 个 新 的 提交 对 
象 。 


上 面 命令 的 输出 即 是 <BRANCH_A_NEW_ROOT> 的 值 。 执 行 下 面 
的 蔡 换 命令 ， 完 成 两 个 分 支 的 巡 接 。 





$ git replace <BRANCH_A_ROOT> <BRANCH_A_NEW_ROOT> 





[1] https:/ /git.wiki.kernel.org/index.php/GraftPoint 


41.5 ”Git 评 注 


从 1.6.6 版 本 开始 ，Git 提 供 了 一 个 git notes 命 令 可 以 为 提交 添加 评 
注 ， 在 不 改变 提交 对 象 的 情况 下 ， 实 现在 提交 说 明 的 后 面 附 加 评注 。 图 
41-1 展 示 了 Github (1 利用 git notes 实 现 的 显示 评注 (如 果 存 在 的 话 ) 和 
添加 评注 的 界面 。 








0 -0,0 +1,6 6 
+#ifndef HELLO WORLD VERSION H 
+#define HELLO WORLD VERSION 片 


* 
| +#define _VERSION “<Version> 
+* 
6 +*#endif 
Git Notes © 


Bisect test: Good commit, for doc/B,txt does not exist. 


0 notes on commit e80aa74 日 Show line notes bolow 0 


Write Proview Comments are parsod with GitHub Flavored Markdown 











图 41-1 Github 上 显示 和 添加 评注 


41.5.1 评注 的 奥秘 


实际 上 Git 的 评注 可 以 针对 任何 对 象 ， 而 且 评 注 的 内 容 也 不 限于 文 
字 ， 因 为 评注 的 内 容 保 存在 Git 对 象 库 中 的 一 个 blob 对 象 中 。 不 过 评注 目 


2 


前 最 主要 的 应 用 还 是 在 提交 说 明 后 添加 文子 评注 。 





在 第 2 篇 第 11 章 的 “11.4.6 二 分 查找 ?中 用 到 的 gitdemo-commit-tree 版 
本 库 实 际 上 就 包含 了 提交 评注 ， 只 不 过 之 前 尚未 将 评注 获取 到 本 地 版 本 
库 而 已 。 如 果 工 作 区 中 的 gitdemo-commit-tree 版 本 库 已 经 不 存在 了 ， 可 
以 使 用 下 面 的 命令 从 Github 上 再 克隆 一 个 : 





$ git clone -q git://github.com/ossxp-com/gitdemo-commit-tree.git 
$ cd gitdemo-commit-tree 





执行 下 面 的 命令 ， 查 看 最 后 一 次 提交 的 提交 说 明 : 





$ git log -1 
commit 6652aQdce6a5067732c00ef0a220810a7230655e 
Author: Jiang Xin <jiangxin@ossxp.com> 
Date: Thu Dec 9 16:07:11 2010 +0800 
Add Images for git treeview. 
Signed-off-by: Jiang Xin <jiangxin@ossxp.com> 





下 面 为 默认 的 origin 远 程 版 本 库 再 添加 一 个 引用 获取 表达 式 ， 以 便 
在 执行 git fetch 命 令 时 能 够 同步 评注 相关 的 引用 。 命 令 如 下 : 





$ git config --add remote.origin.fetch refs/notes/*:refs/notes/* 





执行 git fetch 会 获取 到 一 个 新 的 引用 refs/notes/commits， 如 下 : 





$ git fetch 
remote: Counting objects: 6, done. 
remote: Compressing objects: 100% (5/5), done. 
remote: Total 6 (delta 0), reused 0 (delta 0) 
Unpacking objects: 100% (6/6), done. 
From git://github.com/ossxp-com/gitdemo-commit-tree 
* [new branch] refs/notes/commits -> refs/notes/commits 








当 获 取 新 的 评注 相关 的 引用 之 后 ， 再 来 得 看 最 后 一 次 提 区 的 提交 说 
明 。 下 面 的 命令 输出 中 ， 提 交 说 明 的 最 后 两 行 就 是 附加 的 提交 评注 。 








$ git 10g -1 
commit 6652aQdce6a5067732c00ef0a220810a7230655e 
Author: Jiang Xin <jiangxin@ossxp.com> 
Date: Thu Dec 9 16:07:11 2010 +0800 

Add Images for git treeview. 

Signed-off-by: Jiang Xin <jiangxin@ossxp.com> 
Notes: 

Bisect test: Bad commit, for doc/B.txt exists. 








附加 的 提交 评注 来 自 于 哪里 昵 ? 显然 应 该 和 刚刚 获取 到 的 引用 相 
关 。 查 看 一 下 获取 到 的 最 新 引用 ， 会 发 现 引 用 refs/notes/commits 指 癌 的 


古 一 个 提交 对 象 。 





$ git show-ref refs/notes/commits 
6f01cdc59004892741119318ceb2330d6dcocef1 refs/notes/commits 
$ git cat-file -t refs/notes/commits 

commit 








既然 新 获取 的 评注 引用 是 一 个 提交 对 象 ， 那 么 就 应 该 能 够 查看 评注 
引用 的 提交 日 志 : 





$ git log --stat refs/notes/commits 
commit 6fo1cdc59004892741119318ceb2330d6dcgocef1 
Author: Jiang Xin <jiangxin@ossxp.com> 
Date: Tue Feb 22 09:32:10 2011 +0800 
Notes added by 'git notes add' 
6652a0dce6a5067732c0g0ef0a220810a7230655e | 1+ 
1 files changed, 1 insertions(+), 0 deletions(-) 
commit 9771e1076d2218922acc9800f23d5e78d5894a9f 
Author: Jiang Xin <jiangxin@ossxp.com> 
Date: Tue Feb 22 09:31:54 2011 +0800 
Notes added by 'git notes add' 
e80aa7481beda65ae00e35afc4bc4b171f9boebf | 下 站 
1 files changed, 1 insertions(+), 0 deletions(-) 


OO 一 


从 上 面 的 评注 引用 的 提交 日 志 可 以 看 出 ， 存 在 两 次 提交 ， 并 且 从 提 
交 说 明 可 以 看 出 是 使 用 git notes add 命 令 添加 的 。 至 于 每 次 提交 添加 的 文 
件 却 很 让 人 困惑 ， 所 添加 文件 的 文件 名 居然 是 40 位 的 哈 希 值 。 


您 当然 可 以 通过 git checkout-b 命 令 检 出 该 引用 来 研究 其 中 所 包含 的 
文件 ， 不 过 也 可 以 运用 我 们 已 经 学 习 到 的 Git 命 令 直接 对 其 进行 研究 。 


" 用 git show 命 令 显 示 目 录 树 。 





$ git show -p refs/notes/commits^{tree} 
tree refs/notes/commits^{tree} 
6652a0dce6a5067732c0gef0a220810a7230655e 
e80aa7481beda65ae00e35afc4bc4b171f9boebf 





` 用 git ls-ttee 命 令 查 看 文件 大 小 及 对 应 的 blob 对 象 的 SHA1 哈 希 值 。 





$ git ls-tree -1 refs/notes/commits 
100644 blob 80b1d2...... 47 6652a0...... 
100644 blob e894f2...... 56 e80aar...... 





` 文件 名 既然 是 一 个 40 位 的 SHA1 哈 希 值 ， 那 么 文件 名 一 定 有 意 
义 ， 通 过 下 面 的 命令 可 以 看 到 文件 名 包含 的 和 0 位 哈 希 值 实际 对 应 于 一 





$ git cat-file -p 6652a0Qdce6a5067732c00ef0a220810a7230655e 
tree e33be9e8e7ca5f887c7d5601054f2f510e6744b8 

parent 81993234fc12a325d303eccea20f6fd629412712 

author Jiang Xin <jiangxin@ossxp.com> 1291882031 +0800 
committer Jiang Xin <jiangxin@ossxp.com> 1291882892 +0800 
Add Images for git treeview. 

Signed-off-by: Jiang Xin <jiangxin@ossxp.com> 


3 


用 git cat-file 命 令 查 看 该 文件 的 内 容 ， 可 以 看 到 其 内 容 就 是 附加 在 


相应 提交 上 的 评注 。 





$ git cat-file -p 
refs/notes/commits:6652a0Qdce6a5067732c00ef0a220810a7230655e 
Bisect test: Bad commit, for doc/B.txt exists. 





综 上 所 述 ， 评 注 记录 在 一 个 blob 对 象 中 ， 并 且 以 所 评注 对 象 的 
SHA1 哈 希 值 命名 。 因 为 对 象 SHA1 哈 希 值 的 唯一 性 ， 所 以 可 以 将 评注 都 
放 在 同一 个 文件 系统 下 而 不 会 相互 履 盖 。 针 对 这 个 包含 所 有 评注 的 、 特 
殊 的 文件 系统 的 更 改 被 提交 到 一 个 特殊 的 引用 refs/notes/commits 当 中 。 


41.5.2 ”评注 相关 命令 
Git 提 供 了 git notes 命 令 对 评注 进行 管理 。 如 果 执 行 git notes list， 或 


者 像 下 面 这 样 不 带 任何 参数 进行 调用 ， 会 显示 和 上 面 git ls-tree 类 似 的 输 
出 : 





$ git notes 
80b1d249069959ce5d83d52ef7bd06507f774c2b0 6652a0dce6a5067732c00ef0a220810a7230655e 
e894f2164e77abfO8d95d9bdad4cd51d00b47845 e80aa7481beda65ae00e35afc4bc4b171f9boebf 





石 边 的 一 列 是 要 评注 的 提交 对 象 ， 而 左边 一 列 是 附加 在 对 应 提交 上 
的 包含 评注 内 容 的 blob 对 象 。 显 示 附 加 在 某 个 提交 上 的 评注 可 以 使 用 git 


notes show 命 令 。 如 下 : 





$ git notes Show G^0 


Bisect test: Good commit, for doc/B.txt does not exist. 





注意 上 面 的 命令 中 使 用 G^0 而 非 G， 是 因为 G 是 一 个 里 程 碑 对 象 ， 而 
评注 是 建立 在 由 里 程 碑 对 象 所 指 问 的 一 个 提交 对 象 上 。 


添加 评注 可 以 使 用 下 面 的 git notes add 和 git notes append 子 命令 











用 法 1: git notes add [-f] [-F <file> | -m <msg> | 
用 法 2: git notes append [-F <file> | -m <msg> | (- 














(-c | -C) <object>] [<object>] 
c | -C) <object>] [<object>] 














用 法 1 是 添加 评注 ， 而 用 法 2 是 在 已 有 评注 后 面 妃 加 (修改 已 有 评 
) 。 两 者 的 命令 行 格 式 和 git commit 非 常 类 似 ， 可 以 用 类 似 写 提交 说 
明 的 方法 写 提交 评注 。 如 果 省 略 最 后 一 个 是 <object> 参 数 ， 则 意味 着 问 
头 指针 HEAD 添 加 评注 。 子 命令 git notes add 中 的 参数 -f 意 味 着 强制 添 
加 ， 会 覆盖 对 象 中 己 有 的 评注 。 














使 用 git notes copy 子 命令 可 以 将 一 个 对 象 的 评注 拷贝 到 另外 一 个 对 
象 上 。 




















用 法 : git notes copy [-f] ( --stdin | <from-object> <to-object> ) 








修改 评注 可 以 使 用 下 面 的 git notes edit 子 命令 




















用 法 : git notes edit [<object>] 








删除 评注 可 以 使 用 的 git notes remote 子 命令 ， 而 git notes prune 则 可 


以 清除 已 经 不 存在 的 对 象 上 的 评注 。 用 法 如 下 : 








用 法 1: git notes remove [<object>] 
用 法 2: git notes prune [-n | -v] 























评注 以 文件 形式 保存 在 特殊 的 引用 中 ， 如 果 该 引用 被 共享 并 且 同 时 
有 多 人 撰写 评注 ， 则 可 能 出 现 该 引用 的 合并 冲突 。 可 以 用 git notes merge 
命令 来 解决 合并 冲突 。 评 注 引 用 也 可 以 使 用 其 他 的 引用 名 称 ， 合 并 其 他 
的 评注 引用 也 可 以 使 用 本 命令 。 下 面 是 git notes merge 命 令 的 语法 格式 ， 
具体 操作 请 参见 git help notes 帮 助 。 


























用 法 1: git notes merge [-v | -9q] [-s <strategy> ] <notes_ref> 
用 法 2: git notes merge --commit [-v | -q] 
用 法 3: git notes merge --abort [-v | -9q] 




















41.5.3 ”评注 相关 配置 


默认 提交 评注 保存 在 引用 refsmotes/commits 中 ， 这 个 默认 的 设置 可 
以 通过 core.notesRef 配 置 变量 来 修改 。 如 需 更 改 ， 要 在 core.notesRef 配 置 
变量 中 使 用 引用 的 全 称 而 不 能 使 用 缩写 。 





在 执行 git log 命 令 显 示 提 交 评 注 的 时 候 ， 如 果 配 置 了 
notes.displayRef 配 置 变 量 〈 可 以 使 用 通配符 ， 并 且 可 以 配置 多 个 ) ， 则 
在 显示 提交 评注 时 ， 除 了 会 参考 core.notesRef 设 定 的 引用 《或 默认 的 
refs/notes/commits 引 用 〉 外 ， 还 会 参考 notes.displayRef 指 向 的 引用 (一 








个 或 多 个 ) 来 显示 评注 。 





配置 变量 notes.rewriteRef 用 于 配置 哪个 /哪些 引用 中 的 提交 评注 会 随 
着 提交 的 修改 而 复制 到 新 的 提交 之 上 。 这 个 配置 变量 可 以 使 用 多 次 ， 或 
者 使 用 通配符 ， 但 该 配置 变量 没有 默认 值 ， 因 此 为 了 使 得 提交 评注 能 够 
随 着 提交 的 修改 修补 提交 、 变 基 等 ) 而 继续 保持 ， 必 须 对 该 配置 变量 


进行 设 定 oO 如 : 




















$ git config --global notes.rewriteRef refs/notes/* 





还 有 notes.rewrite.amend 和 和 notes.rewrite.rebase 配 置 变量 可 以 分 别 对 两 
种 提交 修改 模式 〈amend 和 rebase) 是 否 启 用 评注 复制 进行 设置 ， 默 认 
启用 。 配 置 变量 notes.rewriteMode 默 认 设 置 为 concatenate， 即 提交 评注 
复制 到 修改 后 的 提交 时 ， 如 果 已 有 评注 则 对 评注 进行 退 加 操作 。 





[1] https:/ /github.com/ossxp-com/ gitdemo-commit- 
tree/commit/6652a0dce6a5067732c00ef0a220810a220810a7230655e 


第 9 篇 ”附录 
附录 A  Git 命 令 索引 


每 一 个 Git 子 命令 部 和 特定 目录 下 的 一 个 名 为 git-<cmd> 的 文件 相对 
应 ， 也 就 是 在 这 个 特定 目录 下 存在 的 名 为 git-<cmd> 的 可 执行 文件 趾 可 
以 用 命令 git<cmd> 来 执行 。 可 以 用 下 面 的 命令 得 看 这 个 特定 目录 的 位 
置 : 








$ git --exec-path 
/usr/lib/git-core/ 








在 这 个 目录 下 有 150 多 个 可 执行 文件 ， 也 就 是 次 Git 有 非常 多 的 子 命 
令 。 在 如 此 众多 的 子 命令 中 ， 常 用 的 实际 上 只 有 不 到 1/3， 其 余 的 命令 
或 者 作为 撒 层 命令 供 其 他 命令 及 脚本 调用 ， 或 者 用 于 茶 些 生僻 场合 ， 或 
者 已 经 过 时 但 出 于 兼容 性 的 考虑 而 仍然 保留 。 下 面 的 表格 分 门 别 类 地 对 
所 有 的 Git 命 令 进 行 概要 性 的 介绍 ， 几 是 在 本 书 出 现 过 的 命令 将 标 出 其 
所 在 的 章节 号 和 页 码 。 


[1] ”其 中 有 几 个 脚本 不 能 单独 运行 ， 而 是 被 其 他 脚本 包含 ， 用 于 提供 相 
应 的 函数 库 ， 如 git-sh-setup。 
































命令 相关 章节 页 数 
git add 4.1 ; 10.2.3 ; 10.4 添加 至 暂 存 区 
git add--interactive 10.6 交互 式 添加 
git apply 应 用 补丁 
git am 应 用 邮件 格式 补丁 
git annotate 同义词 ， 等 同 于 git blame 
git archive 文件 归档 打包 
git bisect 二 分 查找 
glt blame 文件 逐 行 追 溯 
git branch 18.2 258 分 支管 理 
git cat-file 6.1 83 版 本 库 对 象 研究 工具 
git checkout 8.1 ; 18.4.2 99 ; 262 检 出 到 工作 区 、 切 换 或 创建 分 支 
git cherry-pick 提交 拱 选 
git citool 图 形 化 提交 ， 相 当 于 git gui 命令 
git clean 清除 工作 区 未 跟踪 文件 
git clone 13.1 ; 41.3.2 180 ; 567 克隆 版 本 库 











命令 
git commit 
git config 

git describe 
git diff 

git difftool 
git fetch 

git format-patch 
git grep 

git gui 

git help 

git init 

git init-db 
git log 

pit merge 

git mergetool 
git mv 

git pull 

git push 


git rebase 


TT 
创建 邮件 格 式 的 补丁 文件 。 参 见 stam 命令 
UL | 基于 TWITk 的 加 久 工具 ， 侧 重 提交 等 操作 
版 本 席 初 化 

1 lz | 外 
EE 


ellebase- interadiive | i233 交互 式 分 支 变 基 


git reflog 

git remote 
git repo-config 
git reset 

git rev-parse 
git revert 

git rm 

git show 

git stage 

git stash 

git status 


git tag 


EE 同义词 ， 等 同 于 gitconfig 

将 各 种 引用 表示 法 转换 为 哈 希 值 等 
LE 
Cm 

Cr ET 

TI 


全 
心 


A.2 ”对象 库 操作 相关 从 





命令 相关 章节 简要 说 明 
Skeomimit-ttes 2 从 树 对 象 创建 提交 
ndbjeet 从 标准 输入 或 文件 计算 哈 希 值 或 创建 对 象 
git ls-files 5.3. Lai 显示 工作 区 和 和 暂 存 区 文件 
i 3 显示 树 对 象 包含 的 文件 
se 一 | 读 取 标准 输入 创建 一 个 里 程 牧 对 象 
Si | 一。 | 读 取 标 准 输入 创建 一 个 树 对 象 


LD 
> 
\ 


读 取 树 对 象 到 暂 存 区 

工作 区 内 容 注 册 到 暂 存 区 及 暂 存 区 管理 
创建 临时 文件 包含 指定 blob 的 内 容 

从 暂 存 区 创建 一 个 树 对 象 


git read-tree 
git update-index 


git unpack-file 


LD 


un | 吓 on Ek | 

' = | . |! 
3 | 3 心 | 心 
和 


We | un 
‘0 CN 
An 


glt write-tree 


A.3 引用 操作 相关 命令 


命令 
glt check-ref-format 
glt for-each-ref 

git ls-remote 

git name-rev 

git peek-remote 

glt rev-list 

git show-branch 

glt show-ref 

glt symbolic-ref 


git update-ref 





glt verify-tag 


17.7 248 检查 引用 名 称 是 否 符合 规范 
13.4 186 显示 远程 版 本 库 的 引用 


236 将 提交 ID 显示 为 友好 名 称 


14.1 187 显示 本 地 引用 
显示 或 设置 符号 引用 


校 验 GPG 签名 的 Tag 


A.4 版 本 库 管 理 相关 命令 
































命令 相关 章节 页 数 简要 说 明 
git count-objects 一 一 显示 松散 对 象 的 数量 和 磁盘 占用 
git filter-branch 35.4 511 版 本 库 重 构 
git fsck 14.2 190 对 象 库 完 整 性 检查 
git fsck-objects 一 一 同义词 ， 等 同 于 git fsck 
git gc 14.4 193 版 本 库存 储 优化 
git index-pack 一 = 从 打包 文件 创建 对 应 的 索引 文件 
git lost-found 一 一 过 时 ， 请 使 用 git fsck --lost-found 命令 
git pack-objects 一 一 从 标准 输入 读 入 对 象 中， 打包 到 文件 
git pack-redundant | 一 Es 查找 多 余 的 pack 文件 
git pack-refs 14.1 188 将 引用 打包 到 .git/packed-refs 文件 中 
git prune 14.2 190 从 对 象 库 删除 过 期 对 象 
git prune-packed 一 一 将 已 经 打包 的 松散 对 象 删除 
git relink 一 一 为 本 地 版 本 库 中 相同 的 对 象 建立 硬 连接 
git repack 14.4 193 将 版 本 库 未 打包 的 松散 对 象 打包 
git show-index 14.1 188 读 取 包 的 索引 文件 ， 显 示 打 包 文 件 中 的 内 容 
git unpack-objects | 一 从 打包 文件 释放 文件 
git verify-pack 一 一 校 验 对 象 库 打 包 文 件 


A.5 数据 传输 相关 命令 





命令 相关 章节 页 数 简要 说 明 
区 _ 执行 git fetch 或 git pull 命令 时 在 本 地 执行 此 命令 ， 用 于 
git fetch-pack 1 201 从 其 他 版 本 库 获 取 缺 失 的 对 象 
git receive-pack Es] 201 git push 命令 时 在 远程 执行 的 命令 ， 用 于 接受 推送 的 
i i 有 执行 下 pah 命令 时 在 本 地 执行 的 命令 ， 用 于 向 其 他 且 本 





执行 git archive --remote 命令 基于 远程 版 本 库 创 建 归 档 
时 ， 远 程 版 本 库 执 行 此 命令 传送 归档 


git upload-archive 一 一 





执行 git fetch 或 git pull 命令 时 在 远程 执行 此 命令 ， 将 对 


git upload-pack 15:1 201 象 打 包 、 上 传 








A.6 邮件 相关 命令 


命令 
glt 1map-send 
gilt mailinfo 
git mailsplit 
glt request-pull 


git send-email 


相关 章节 页 数 简要 说 明 


21:2 江 313 创建 包含 提交 间 差 异 和 执行 PULL 操作 地 址 的 信息 
20.1 297 发 送 邮 件 


A.7 协议 相关 命令 






































命令 相关 章节 页 数 简要 说 明 
git daemon 406 实现 Git 协议 
git http-backend 人 272 400 实现 HTTP 协议 的 CGI 程序， 支持 智能 HITP 协议 
git instaweb 405 即时 启动 浏览 器 通过 gitweb 浏览 当前 版 本 库 
git shell 一 受 限 制 的 shell， 提 供 仅 执行 Git 命令 的 SSH 访问 
git update-server-info | 15.1 201 更 新 中 协议 需要 的 辅助 文件 
git http-fetch 一 通过 HITP 协议 获取 版 本 库 
git http-push 一 通过 HITP/DAYV 协议 推送 
git remote-ext 三 一 > 由 Git 命令 调用 ， 通 过 外 部 命令 提供 扩展 协议 支持 
git remote-fd 一 上 由 Git 命令 调 用 ， 使 用 文件 描述 符 作为 协议 接口 
sit remote-ftp 由 Git 命令 调用 ， 提 供 对 FTP 协议 的 支持 
git remote-ftps 一 由 Git 命令 调用 ， 提 供 对 FTPS 协议 的 支持 
git remote-http 三 一 3 由 Git 命令 调用 ， 提 供 对 HTTP 协议 的 支持 
git remote-https 一 由 Git 命令 调用 ， 提 供 对 HTTPS 协议 的 支持 
git remote-testgit -一 一 一 协议 扩展 示例 脚本 


A.8 版 本 库 转换 和 交互 相关 命令 


命令 相关 章 市 页 数 简要 说 明 





git archimport 一 导入 Arch 版 本 库 到 Git 


git bundle 提交 打包 和 解 包 ， 以 便 在 不 同 版 本 库 间 传递 











git fast-import 


506 其 他 版 本 库 迁 移 至 Git 的 通用 工具 





git svn 380 Git 作为 前 端 操作 Subversion 





> 
git cvsexportcommit -一 将 Git 的 一 个 提交 作为 一 个 CVS 检 出 
git cvsimport 一 导入 CVS 版 本 库 到 Git， 或 者 使 用 cvs2git 
git cvsserver 一 Git 的 CVS 协议 模拟 器 ， 可 供 CVS 命令 访问 Git 版 本 库 
git fast-export = 将 提交 导出 为 git-fast-impott 格式 
33:3 
26.1 


A.9 合并 相关 的 辅助 命令 





命令 相关 章节 页 数 简要 说 明 
git merge-base 11.4.2 146 供 其 他 脚本 调用 ， 找 到 两 个 或 多 个 提交 最 近 的 共同 祖先 





git merge-file 


针对 文件 的 两 个 不 同 版 本 执行 三 向 文件 合并 





git merge-index 
git merge-octopus 
gilt merge-one-file 


git merge-ours 


对 index 中 的 冲突 文件 调用 指定 的 冲突 解决 工具 
合并 两 个 以 上 的 分 支 。 参 见 git merge 的 octopus 合并 策略 
由 git merge-index 调用 的 标准 辅助 程序 


合并 使 用 本 地 版 本 ， 抛 弃 他 人 版 本 。 参 见 git merge 的 ours 
合并 策略 





glt merge-recursive 


针对 两 个 分 支 的 三 向 合并 。 参 见 git merge 的 recursive 合 
并 策略 





git merge-resolve 
git merge-subtree 
git merge-tree 


git fmt-merge-msg 


针对 两 个 分 支 的 三 向 合并 。 参 见 git merge 的 resolve 合并 
策略 


子 树 合并 。 参 见 git merge 的 subtree 合并 策略 
显 式 三 向 合并 结果 ， 不 改变 暂 存 区 
供 执行 合并 操作 的 脚本 调用 ， 用 于 创建 一 个 合并 提交 说 明 





git rerere 





重用 所 记录 的 冲突 解决 方案 


A 
.10 ”杂项 


命令 相关 章节 页 数 简要 说 明 


git bisect--helper 一 |- | 由 git bisect 命令 调用 ， 确 认 二 分 查找 进度 
Sitcheclcatt 显示 某 个 文件 是 否 设置 了 某 个 属性 

git checkout-index 一 |- | 从 暂 存 区 拷贝 文件 至 工作 区 

cielo 查找 没有 合并 到 上 游 的 提交 

55 EE 比较 暂 存 区 和 工作 区 ， 相 当 于 git diff --raw 

git difindex 一 | | 比较 暂 存 区 和 版 本 库 ， 相 当 于 git diff--cached --raw 
Sit df:tree 一 | 一 |e 较 两 个 树 对 象 ， 相当 于 gitdiff -rawAB 
gitdiffiool-helper | 一 | 一 | 由 gitdifhool 命 令 调 用 ， 默认 要 使 用 的 差异 比较 工具 
git get-tar-commit-id op | 从 git archive 创建 的 tar 包 中 提取 提交 ID 


git gui--askpass 命令 git gui 的 获取 用 户口 令 输 入 界面 


un 
~ 


删除 空 行 ， 供 其 他 脚本 调用 

git submodule 23.1 337 子 模 组 管理 

过 时 命令 ， 请 使 用 git archive 
显示 Git 环境 变量 
启动 浏览 器 以 查看 目录 或 文件 
显示 提交 历史 及 每 次 提交 的 改动 


包含 于 其 他 脚本 中 ， 提 供 合并 /差异 比较 工具 的 
选择 和 执行 


包含 于 其 他 脚本 中 ， 提 供 操作 远程 版 本 库 的 函数 
包含 于 其 他 脚本 中 ， 提 供 shell 编程 的 函数 库 


git stripspace 


= | 
git notes 提交 评论 管理 
Wh 一 | 补丁 过 滤 行 号 和 空白 字符 后 生成 补丁 唯一 ID 
git quiltimport 305 将 Quilt 补丁 列表 应 用 到 当前 分 支 
gitreplace 569 提交 替换 
or 一 | 对 git log 的 汇总 输出 ， 适 合 于 产品 发 布 说 明 
| 


git tar-tree 
git var 
git web--browse 


git whatchanged 
git-mergetool--lib 


git-parse-remote 


git-sh-setup 


附录 B Git 与 CVS 面 对 面 
B.1 面对面 访谈 录 
Git， 我 的 提交 是 原子 提交 。 每 次 提交 都 对 应 于 一 个 目录 树 〈 树 对 


象 ) 。 因 为 我 的 提交 ID 是 对 目录 树 及 相关 的 提交 信息 建立 的 一 个 SHA1 
哈 布 值 ， 所 以 可 以 保证 数据 的 完整 性 。 








CVS: 我 承认 这 是 我 的 软肋 ， 一 次 错误 或 冲突 的 提交 会 导致 部 分 数 
据 被 提交 ， 而 部 分 数据 没有 提交 ， 版 本 库 的 完整 性 会 被 破坏 ， 所 以 人 们 
才 设 计 出 来 Subversion (SVN) 来 取代 我 。 


Git: 我 的 分 文 和 里 程 碑 管 理 非常 快捷 。 因 为 我 的 分 文 和 里 程 碑 束 
是 一 个 记录 提交 ID 的 40 字 节 的 文件 ， 你 的 呢 ? 


CVS: 你 怎么 又 提 到 别人 的 痛处 了 ! 我 的 分 支 和 里 程 碑 创建 速度 还 
芭 很 快 和 的， 本 本 ， 如 果 在 版 本 库 中 只 有 几 个 文件 的 话 。 当 然 如 果 
版 本 库 中 的 文件 很 多 ， 创 建 分 支 和 里 程 碑 就 需要 花费 很 长 的 时 间 。 有 些 
人 对 此 忍无可忍 ， 于 是 设计 出 SVN 来 取代 我 。 





Git: 其 实 我 不 用 里 程 碑 都 没有 关系 ， 因 为 每 个 提交 有 DD 就 对 应 于 唯 


一 的 一 个 提交 状态 。 


CVS: 这 也 是 我 做 不 到 的 。 我 没有 全 局 版 本 号 的 概念 ， 每 个 文件 都 
通过 单独 的 版 本 号 记录 其 变更 历史 ， 所 以 人 们 在 使 用 我 的 时 候 必 须 经 常 
用 里 程 碑 (tag) 对 我 的 状态 进行 标识 。 还 需要 提醒 一 句 的 是 ， 如 果 版 本 
库 中 的 文件 太 多 ， 创 建 里程 碑 是 很 耗 时 的 ， 因 为 要 逐一 打开 每 个 版 本 库 
中 的 文件 ， 并 在 其 中 记录 里 程 碑 和 文件 版 本 的 关联 。 





Git: 我 的 工作 区 很 干净 。 只 在 工作 区 的 根 目录 下 有 一 个 .git 目 录 ， 
此 外 再 无 其 他 辅助 目录 或 文件 。 


CVS: 我 要 在 工作 区 的 每 一 个 目录 下 都 放置 一 个 CVS 目 录 ， 这 个 目 
录 下 有 个 Entries 文 件 很 重要 ， 记 录 了 对 应 工作 区 文件 的 检 出 版 本 及 时 间 
稚 等 信息 。 这 样 做 的 好 处 是 可 以 将 工作 区 移动 到 任何 其 他 磁盘 和 目录 ， 
而 毫 不 影响 使 用 ， 甚 至 我 可 以 将 工作 区 的 一 个 子 目 录 拿 出 来 ， 作 为 独立 
的 工作 区 。 


Git: 我 也 可 以 将 工作 区 移动 到 其 他 磁盘 ， 但 是 要 保证 工作 区 下 
的 .git 目 录 和 工作 区 一 同 移动 。 不 可 以 只 移动 工作 区 下 的 一 个 目录 到 其 
他 磁盘 或 目录 ， 那 样 的 话 移出 的 目录 就 不 能 工作 了 。 











Git: 我 的 网 络 传输 效率 很 高 。 在 和 其 他 版 本 库 交 互 时 ， 对 方 会 告 
诉 我 他 有 什么 ， 我 也 知道 我 有 什么 ， 因 为 只 传输 缺失 对 象 的 打包 文件 ， 
所 以 效率 很 高 而 且 能 够 显示 传输 进度 。 


CVS: 这 一 点 我 不 行 。 因 为 我 本 地 没有 文件 做 对 照 ， 所 以 我 在 传输 


的 时 候 不 可 能 做 到 增 量 传输 。 








Git: 我 甚至 可 以 不 需要 网 络 ， 因 为 我 在 本 地 拥有 完整 的 版 本 库 ， 
几乎 所 有 的 操作 都 在 本 地 完成 。 


CVS: 我 的 操作 处 处 需要 网 络 ， 如 果 版 本 库 在 网 络 中 的 其 他 服务 器 
上 ,而 且 网 速 又 比较 慢 ， 那么 查看 日 志 或 历史 版 本 都 需要 等 很 长 时 间 。 


CVS: 你 怎么 没有 更 新 (update) 命令 ? 还 有 你 为 什么 老 是 要 执行 
检 出 命令 (checkout) ? 对 我 而 言 ， 检 出 命令 只 在 工作 区 创建 时 一 次 性 
完成 。 


Git: 你 的 检 出 命令 (checkout〉 是 从 远程 版 本 库 服务 器 获取 数据 来 
完成 本 地 工作 区 的 创建 ， 版 本 库 仍 然 位 于 远程 服务 器 上 。 你 的 更 新 
Cupdate) 命令 执行 得 很 慢 ， 对 吗 ? 之 所 以 你 需要 执行 更 新 命令 是 因为 
你 的 版 本 库 在 远程 啊 。 别 忘 了 我 的 版 本 库 是 在 本 地 ， 本 地 版 本 库 会 随 着 
我 在 本 地 工作 区 中 的 操作 (如 提交 ) 而 更 新 。 我 的 检 出 (checkout) 操 
作 是 将 本 地 版 本 库 的 数据 检 出 到 本 地 工作 区 ， 用 于 恢复 本 地 丢失 或 错误 
改动 的 文件 ， 也 用 于 切换 不 同 的 分 支 。 我 也 有 一 个 和 你 的 更 新 
(update ) 操作 类 似 的 、 比 较 耗 时 的 网 络 操作 命令 : git fetch 或 git pull， 
这 两 个 操作 是 从 别人 的 版 本 库 获 取 他 人 的 改动 。 一 般 使 用 我 〈Git) 做 
团队 协作 的 时 候 ， 会 部 署 一 个 集中 共享 的 版 本 库 ， 我 就 用 这 两 个 命令 
(git fetch 或 git pull) 从 共享 的 版 本 库 执 行 拉 回 操作 。 也 许 你 〈《CVS) 会 








觉得 git fetch 或 git pull 和 你 的 cvs update 命 令 更 像 吧 。 至 于 你 的 检 出 命令 
Ccvs checkout) ， 实 际 上 和 我 的 克隆 命令 (git clone) 很 相似 ， 只 不 过 
我 的 克隆 命令 不 但 创建 了 本 地 工作 区 ， 而 且 在 本 地 还 复制 了 和 远程 版 本 
库 一 样 的 本 地 版 本 库 。 





CVS: 为 什么 你 的 检 入 (commit) 命令 执行 得 那么 快 ? 





Git: 是 的 ， 我 的 检 入 命令 飞 一 般 就 执行 完了 ， 这 也 是 因为 版 本 库 
就 在 本 地 。 也 许 你 (CVS) ee 
命令 (cvs commit) 更 相像 ， 个 误会 。 如 果 我 不 做 本 地 提 
交 ， 是 没有 东西 可 以 推送 (git push) 的 。 你 (CVS) 每 一 次 提交 都 要 和 
版 本 库 进 行 网 络 通信 ， 而 我 可 以 在 本 地 版 本 库 进 行 多 次 提交 ， 直 到 我 的 
主人 想 喝 咖啡 了 才 执 行 一 次 git push， 将 我 本 地 版 本 库 中 的 新 提交 推送 给 
远程 版 本 库 。 








CVS: 我 每 个 文件 都 一 个 独立 的 版 本 号 ， 你 有 吗 ? 


Git: 每 个 文件 一 个 版 本 号 ? 这 有 什么 值得 夸耀 的 ? 我 昕 说 你 最 早 
征用 脚本 对 RCS 系 统 进行 封装 实现 的 ， 所 以 你 的 每 个 文件 都 有 一 个 独立 
的 版 本 控制 ， 这 让 你 变 得 很 零碎 。 我 听 说 菜 些 商业 版 本 控制 系统 也 是 这 
样 ， 真 糟糕 。 我 的 每 次 提交 都 有 一 个 全 球 唯一 的 版 本 扎 ， 不 但 在 本 地 版 
本 库 中 是 唯一 的 ， 和 其 他 人 的 版 本 库 也 不 会 有 冲突 。 














CVS: 我 能 一 次 检 出 一 个 目录 ， 你 好 像 不 能 吧 ? 


Git: 所 以 我 有 子 模 组 ， 以 及 repo 等 第 三 方 工具 ， 可 以 帮助 我 把 一 个 
大 的 版 本 库 拆 成 多 个 版 本 库 组 合 来 使 用 啊 。 而 且 我 还 有 黎 芷 检 出 的 功 
能 ， 只 不 过 很 少 有 人 用 到 罢了 。 


CVS: 我 能 添加 空 目 录 ， 你 好 像 不 能 吧 ? 








Git: 是 的 ， 我 现在 还 不 能 记录 空 目 录 。 但 是 用 户 可 以 在 空 目录 下 
创建 一 个 隐 含 文件， 并 将 该 隐 含 文件 添加 到 版 本 库 中 ， 这 整 实 现 了 空 目 
录 的 添加 功能 。 你 ，CVS， 目 录 管 理 是 你 的 软肋 ， 你 很 难 实现 目录 的 重 
命名 ， 而 目录 重 命名 对 我 来 说 却 是 小 潜 一 催 。 














B.2 _Git 和 CVS 命 令 对 照 


比较 项 目 


URL 


版 本 库 初 始 化 
导入 数据 
版 本 库 检 出 

版 本 库 分 支 检 出 
工作 区 更 新 

更 新 至 历史 版 本 
更 新 到 指定 日 期 
更 新 至 最 新 提交 
切换 至 里 程 碑 
切换 至 分 支 

还 原文 件 / 强制 米 盖 
添加 文件 

添加 文件 〈 二 进 制 ) 
删除 文件 

移动 文件 
反 删 除 文件 


工作 区 差异 比较 


版 本 间 差 异 比较 
查看 工作 区 状态 
提交 

显示 提交 日 志 


CVS 命令 GIT 命令 
:pserver:user(@host:/path/to/cvsroot git://host/path/to/repos.git 
/path/to/cvsroot ssh://user(@Dhost/path/to/repos.git 


user(@host:path/to/repos.git 


file:///path/to/repos.git 
/path/to/repos.git 

cvs -d <path> init git init [--bare] <path> 

Cvs -d <url> import -m git clone; git add .; git commit 

cvs -d <url> checkout [-d <path>] <module> git clone <url> <path> 

cvs -d <url> checkout -r <branch> <module> git clone -b <branch> <url> 

ei eheokou HEAD@ (ciate 

git diff 

cvs diff -u git diff --cached 
git diff HEAD 

cvs diff -u -r <revl> -r <rev2> <path> ee <commitl> <commit2> -- 

cvs commit -m "<msg>" git commit -a -m "<msg>" ; git push 


cvs log <path> | less git log 





比较 项 目 
逐 行 追 济 


显示 里 程 碑 /分 支 


创建 里 程 碑 
删除 里 程 碑 


创建 分 支 


删除 分 支 


导出 项 目 文件 


显示 文件 列表 
更 改 提 交 说 明 


撤销 提交 


杂项 








CVS 命令 GIT 命令 
it ta 
Cvs Status -V 
git branch 
it tag [-m "<msg>"] <tagname> 
cvs tag [-r <rev>] <tagname> . 8 8 | g>"] B 
[<commit>] 
cvs rtag -d <tagname> git tag -d <tagname> 


git branch <branch> <commit> 
cvs rtag -b -r <rev> -b <branch> <module> 
git checkout -b <branch> <commit> 


cvs rtag -d <branch> git branch -d <branch> 


git archive -0 <output.tar> <tag> 
<path> 

git archive -o <output.tar> 
--remote=<url> <tag> <path> 


cvs -d <url> export -r <tag> <module> 


cvs update [-j <start>] -j <end>; cvs commit git merge <branch> 
jevsadmin-o<range><path> | git reset [ --soft | --hard ] HEADY^ 


参数 -kv 开启 关键 字 扩 展 export-subst 属性 


附录 C ”Git 与 SVN 面 对 面 


C.1 面对面 访谈 录 








Git: 我 的 提交 历史 本 里 就 是 一 幅 美 丽 的 图 画 一 一 DAG (Directed 
Acylic Graph， 有 向 无 环 图 ) ， 可 以 看 到 各 个 分 支 之 间 的 合并 关系 。 而 
你 SVN， 你 的 提交 历史 怎么 是 一 条 直线 呢 ? 要 是 在 重症 监护 室 看 到 你 ， 
还 以 为 你 挂 掉 了 呢 ? 








SVN: 我 觉得 插 好 ， 至 少 我 每 次 提交 会 有 一 个 全 局 的 版 本 号 ， 而 且 


我 的 版 本 号 是 递增 的 。 你 的 版 本 号 不 是 递增 的 吧 ? 


Git: 你 次 的 对 ， 我 的 版 本 号 不 是 一 个 简单 递增 的 数字 ， 而 是 一 个 
长 达 40 位 的 十 六 进 制 数字 《 哈 希 值 ) ， 但 是 可 以 使 用 短 格式 ， 只 要 不 冲 
突 。 虽 然 我 的 提交 编号 看 起 来 似乎 是 无 序 的 ， 但 实际 上 我 的 每 一 个 提交 
都 记录 了 父 提 交 甚 至 是 双 杀 或 多 杀 提 交 ， 因 此 可 以 很 容易 地 从 任意 一 个 
提交 开始 建立 一 条 指 问 历 史 提交 的 跟 踊 链 。 











SVN: 是 啊 ， 我 的 一 个 提交 和 前 一 个 提交 有 时 根本 没有 关系 ， 例 如 
一 个 提交 是 发 生 在 主线 /trunk 中 的 ， 下 一 个 提交 可 能 就 发 生 
在 /branches/1.3.x 分 支 中 。 你 要 知道 ， 要 想 画 出 一 个 像 你 那样 的 分 支 
图 ， 我 要 做 多 少 工 作 吗 ?我 不 容易 呀 。 


Git: 我 一 直 很 奇怪 ， 你 的 分 文 和 里 程 碑 怎 么 看 起 来 和 目录 一 样 ? 
我 的 分 文 和 里 程 碑 名 字 昌 然 看 起 来 像 是 目录 ， 但 实际 上 和 工作 区 的 目录 


完全 没有 关系 ， 只 是 对 提交 ID 的 一 个 记号 而 已 。 








SVN: 我 一 开始 觉得 我 用 轻 量 级 拷贝 的 方式 实现 分 支 和 里 程 碑 会 很 
酷 ， 也 很 快 。 但 是 我 发 现 很 多 人 在 使 用 我 的 时 候 ， 直 接 在 版 本 库 的 根 目 
录 下 创建 文件 而 不 是 把 文件 创建 在 /trunk 目 录 下 ， 这 就 导致 这 些 人 无 法 
再 创建 分 支 和 里 程 碑 了 ， 因 为 无 法 将 根 目录 拷 贝 到 子 目录 呀 ! 


Git: 那么 你 是 如 何 对 分 文 合 并 进行 跟踪 的 呢 ? 因为 我 有 DAG 的 提 
交 关 系 图 ， 很 容易 就 可 以 看 出 分 文 之 间 的 合并 历史 ， 但 是 你 是 怎么 做 到 
的 呢 ? 





SVN: 我 用 了 一 点 小 技巧 ， 通 过 属性 (svn:mergeinfo) 记录 了 合并 
的 分 支 名 和 版 本 范围 ， 这 样 再 合并 的 时 候 ， 我 会 根据 相关 属性 确定 是 否 
要 合并 。 但 是 如 果 经 常 在 子 目 录 下 合并 ， 会 有 太 多 的 svn:mergeinfo 属 性 
等 待 我 检查 ， 我 会 很 困扰 。 还 有 我 的 这 个 功能 是 在 1.5 以 后 的 版 本 才 提 供 
的 ， 因 此 老 版 本 会 破坏 这 个 机 制 。 


SVN: 对 了 ， 我 的 属性 能 干 很 多 事 哦 ， 我 其 至 可 以 把 我 的 照片 作为 
属性 附加 在 文件 上 。 





Git: 这 点 我 承认 ， 你 的 属性 非常 强大 。 其 实 我 也 文 持 属性 ， 只 不 
过 实现 方式 不 同 罢 了 。 而 且 我 可 以 通过 评注 的 方式 为 任意 对 象 〈 提 交 、 








文件 、 里 程 碑 等 ) 添加 评注 ， 也 可 以 实现 把 照片 作为 评注 附加 在 文件 
上 ， 可 是 这 个 功能 有 什么 实际 用 处 呢 ? 


SVN: 我 有 轻 量 级 拷贝 ， 而 我 的 分 支 和 里 程 碑 就 是 通过 拷贝 实现 
的 ， 很 强大 哦 。 


Git: 我 根本 就 不 需要 轻 量 级 拷贝 ， 因 为 我 对 文件 的 保存 和 文件 的 
路 径 无 天， 我 只 关心 内 容 。 所 以 相同 内 容 的 文件 无 论 它 们 的 文件 名 相差 
有 多 大 ， 在 我 这 里 只 保存 一 份 。 而 你 SVN， 如 果 用 户 筷 了 用 轻 量 级 找 
贝 ， 版 本 库 是 不 是 负担 很 重 啊 。 





SVN: 听 说 你 不 能 针对 目录 授权 ， 这 可 是 我 的 强项 ， 所 以 公司 无 论 
大 小 都 在 用 我 作为 版 本 控制 系统 。 


Git: 不 要 说 你 的 授权 了 ， 简 直 是 一 团 糟 。 虽 然 这 本 书 的 作者 为 你 
写 了 一 个 图 形 化 的 授权 管理 工具 上 ， 对 你 的 授权 会 有 所 改善 ， 但 是 你 
糟糕 的 分 文 和 里 程 碑 的 实现 ， 会 导致 授权 在 新 的 分 支 和 和 里程碑 中 又 要 逐 
一 进行 设置 ， 工 作 量 其 大 无 比 。 虽 然 泛 路 径 授权 是 一 个 解决 方案 ， 但 是 
官方 并 没有 提供 啊 。 





Git: 说 说 我 的 授权 吧 。 如 果 你 认真 地 读 过 本 书 服务 占 架 设 的 相关 
章节 ， 你 会 为 我 能 够 提供 按照 分 文 ， 以 及 按照 路 径 进行 写 操作 授权 的 功 
能 而 击 营 叫好 的 。 当 然 我 的 读 操 作 授权 还 不 能 做 到 很 精细 ， 但 是 可 以 将 
版 本 库 拆 分 成 符 干 个 小 的 版 本 库 啊 ， 再 参照 本 书 介绍 的 各 种 多 版 本 库 协 





同 模式 ， 也 会 找到 一 个 适合 的 解决 方案 的 啊 。 





Git: 我 的 工作 区 很 干净 。 只 在 工作 区 的 根 目录 下 有 一 个 .git 目 录 ， 
此 外 再 无 其 他 。 


SVN: 我 要 在 工作 区 的 每 一 个 目录 下 都 放置 一 个 .svn 目 录 ， 这 个 目 
录 在 Linux 下 可 是 隐藏 的 哦 。 这 个 目录 下 不 但 有 跟踪 工作 区 文件 状态 的 
跟踪 文件 ， 而 且 还 有 每 一 个 文件 的 原始 拷贝 呢 。 这 样 有 的 操作 就 可 以 脱 
离 网 络 执行 了 ， 例 如 : 差异 比较 、 工 作 区 文件 的 回 滚 。 





Git: 嗯 ， 你 要 是 像 我 一 样 能 再 多 保存 一 点 内 容 〈 整 个 版 本 库 ) 网 
更 好 了 。 像 你 这 样 在 每 个 工作 区 子 目录 下 都 有 一 个 .svn 目 录 ， 而 且 每 
个 .svn 目 录 下 都 有 文件 的 原始 拷贝 ， 在 进行 内 容 搜索 的 时 候 会 搜索 出 两 
份 吧 ， 太 干扰 了 。 而 且 你 这 么 做 和 CVS 一 样 有 安全 风险 ， 造 成 本 地 文件 
名 的 信息 泄漏 ， 千 万 不 要 在 web 服务器 上 用 SVN 检 出 哦 。 











Git: 我 的 操作 可 以 不 需要 网 络 。 因 为 我 在 本 地 拥有 完整 的 版 本 
库 ， 几 乎 所 有 操作 都 是 在 本 地 完成 的 。 


SVN: 正如 前 面 说 到 的 ， 我 有 部 分 命令 可 以 不 需要 网 络 ， 但 是 其 他 


绝 大 多 数 命 令 还 是 要 依赖 网 络 的 。 


SVN: 你 怎么 没有 更 新 (update) 命令 啊 ? 还 有 你 为 什么 老 是 要 执 
行 检 出 命令 (checkout) ? 对 我 而 言 ， 检 出 命令 只 在 工作 区 创建 时 一 次 


Git: 你 的 这 个 问题 怎么 和 CVS 问 的 一 样 。 你 的 更 新 (update) 命令 
执行 的 很 慢 ， 对 吧 ? 首先 你 要 用 检 出 命令 〈checkout) 建立 工作 区 ， 然 
后 你 要 经 常 执行 更 新 〈update) 命令 进行 更 新 ， 和 否则 很 容易 造成 你 的 更 
改 和 他 人 的 更 改 发 生 冲 突 。 














Git: 之 所 以 你 需要 更 新 是 因为 你 的 版 本 库 在 远程 啊 。 别 忘 了 我 的 
版 本 库 是 在 本 地 ， 本 地 的 版 本 库 会 随 着 我 在 本 地 工作 区 中 的 操作 (如 提 
交 ) 而 更 新 。 我 的 检 出 (checkout) 操作 一 般 用 于 用 户 切 换 分 支 ， 或 者 
从 本 地 版 本 库 检 出 丢失 的 文件 或 覆盖 本 地 错误 改动 的 文件 。 如 果 我 没 记 
错 的 话 ， 你 切换 分 文 用 的 是 svn switch 命 令 对 么 ? 


Git: 实际 上 我 也 有 一 个 比较 耗 时 的 网 络 操作 命令 : git fetch 或 git 
pul， 这 两 个 操作 是 从 远程 版 本 库 获 取 他 人 的 改动 。 一 般 使 用 我 〈Git) 
做 团队 协作 的 时 候 ， 会 部 署 一 个 集中 共享 的 版 本 库 ， 我 就 从 这 个 共享 的 
版 本 库 执行 拉 回 操作 。 也 许 你 SVN) 会 觉得 git fetch 或 git pull 和 你 的 
svn update 命 令 更 像 吧 。 至 于 你 的 检 出 命令 (svn checkout) ， 实 际 上 和 
我 的 克隆 命令 git alone) 很 相似 ， 只 不 过 我 的 克隆 命令 不 但 创建 了 本 
地 工作 区 ， 而 且 在 本 地 还 复制 了 和 远程 版 本 库 一 样 的 本 地 版 本 库 。 





SVN: 为 什么 你 的 检 入 (commit) 命令 执行 得 那么 快 ? 


Git: 是 的 ， 我 的 检 入 命令 飞 一 般 就 执行 完了 ， 这 也 是 因为 我 的 版 


本 库 就 在 本 地 。 也 许 你 (SVN) 会 觉得 我 的 推送 命令 〈git push) 和 你 的 
检 入 命令 (svn commit) 更 相像 ， 其 实 这 是 一 个 误会 。 如 果 我 不 做 本 地 
提交 ， 是 不 能 通过 推送 命令 〈git push) 将 我 的 本 地 提交 共享 给 (推送 
给 ) 其 他 版 本 库 的 。 你 ‘SVN) 每 一 次 的 提交 都 要 和 版 本 库 进 行 网 络 通 
言 ， 而 我 可 以 在 本 地 版 本 库 进 行 多 次 提交 ， 直 到 我 的 主人 想 喝 咖啡 了 才 
执行 一 次 git push， 将 我 本 地 版 本 库 中 的 新 提交 推送 给 远程 版 本 库 。 





SVN: 我 能 一 次 检 出 一 个 目录 ， 你 好 像 不 能 吧 ? 


Git: 所 以 我 有 子 模 组 ， 以 及 repo 等 第 三 方 工具 ， 可 以 帮助 我 把 一 个 
大 的 版 本 库 拆 成 多 个 版 本 库 组 合 来 使 用 啊 。 而 且 我 还 有 稀 朴 检 出 的 功 
能 ， 只 不 过 很 少 有 人 用 到 罢了 。 





SVN: 我 能 添加 空 目录 ， 你 好 像 不 能 吧 ? 








Git: 是 的 ， 我 现在 还 不 能 记录 空 目录 ， 但 是 用 户 往往 在 空 目录 下 
创建 一 个 隐 仿 文件， 并 将 该 隐 侣 文件 添加 到 版 本 库 中 ， 这 融 实 现 了 空 目 
录 添 加 的 功能 








[1] http:/ /www.ossxp.com/doc/pysvnmanager/user-guide/user-guide.html 


C.2 Git 和 和 SVN 命令 对 有 


比较 项 目 


版 本 库 初 始 化 
导入 数据 
版 本 库 检 出 
版 本 库 分 支 检 出 


DY 


过 


svn://host/path/to/repos 
https://host/path/to/repos 


file:///path/to/repos 


svnadmin create <path> 
svn import <path> <url> -m ... 
svn checkout <url/of/trunk> <path> 


svn checkout <url/of/branches/name> <path> 


GIT 命令 
git://host/path/to/repos.git 
ssh://user@host/path/to/repos.git 
user(@host:path/to/repos.git 
file:///path/to/repos.git 
/path/to/repos.git 

glt init [--bare] <path> 

glt clone; git add .; git commit 
git clone <url> <path> 


git clone -b <branch> <url> <path> 


( 续 ) 





更 新 至 历史 版 本 git checkout <commit> 
更 新 到 指定 日 期 git checkout HEAD(@'{<date>}" 
I jcm | 
获取 文件 历史 版 本 git show <commit>:<path> > <output> 
git diff 
工作 区 差异 比较 svn diff git diff --cached 
git diff HEAD 
版 本 间 差异 比较 git di 他 <commitl> <commit2> -- <path> 
提交 svn commit -m "<msg>" git commit -a -m "<msg>" ; git push 
创建 里 程 碑 a "<msg>"] <tagname> 
创建 分 支 svn cp <url/of/trunk/> git branch <branch> <commit> | 
<url/of/branches/name> git checkout -b <branch> <commit> 




















比较 项 目 SVN 命令 GIT 命令 
svn export -T <rev> <path> <output/path> git archive -o <output.tar> <commit> 
导出 项 目 文件 git archive -o <output.tar> 
svn export -T <rev> <url> <output/path> : 
--remote=<url> <commit> 
反 转 提交 svn merge -c -<TeV> git revert <commit> 
提交 拒 选 svn merge -c <TeV> git cherry-pick <commit> 
分 支 合并 svn merge <url/of/branch> git merge <branch> 
svn resolve --accept=<ARG> <path> git mergetool 
冲突 解决 
svn resolved <path> git add <path> 
svn ls git ls-files 
显示 文件 列表 ; 
svn ls <url> -r <rev> git ls-tree <commit> 
更 改 提交 说 明 SVD ps --revprop -r<Tev> svn:log "<msg>" git commit --amend 
撤销 提交 svnadmin dump、svnadmin load 及 svndumpfilter | git Teset [ --soft | --hard ] HEAD^ 
svn:ignore .gitignore 文件 
svn:mime-type text 属性 
属性 svn:eol-style eol 属性 


svn:externals 


git submodule 命令 





svn:keywords 





export-subst 属性 


附录 D Git 与 Hg 面对面 


D.1 和 面对面 访谈 录 


: 你 好 Hg， 我 发 现 我 们 真 的 很 像 


Hg: 是 啊 ， 人 们 把 我 们 都 归 类 为 分 布 式 版 本 控制 工具 ， 所 以 我 们 
之 间 的 相似 度 ， 要 比 和 CVS、SVN 的 相似 度 高 得 多 了 。 
Hg: 我 是 用 Python 和 少 部 分 的 C 语 言 实现 的 ， 你 呢 ? 


启 


/> 


我 的 核心 当然 是 使 用 C 语 言 了 ， 因 为 Linus Torvalds 最 爱 用 C 语 
和 了。 我 的 很 多 命令 还 使 用 了 Shell 脚 本 和 Perl 语 言 开发 ， 


Python 用 的 很 


Hg: 大 量 使 用 C 语 言 ， 是 你 的 性 能 比 我 高 的 原因 吗 ? 
Git: 当 





当然 不 是 了 ， 你 不 也 在 核心 模块 使 用 C 语 言 了 么 ?问题 的 关键 
在 于 我 的 对 象 库 设计 得 非常 优秀 。 你 不 
目 





了 我 是 谁 发 明 的 ， 那 可 是 大 
名 易 易 的 Linux 之 父 Linus Torvalds 啊 ， 他 对 Linux 文 件 系统 可 是 再 熟悉 不 
的 了 ， 所 以 他 能 够 以 文件 系统 开发 者 的 视角 来 实现 我 的 核心 
还 有 我 的 网 络 传输 过 





填 程 非常 直观 ， 可 以 显示 实时 的 进度 ， 好 


像 我 从 你 那里 没有 看 到 。 之 所 以 我 能 够 有 这 样 的 实现 ， 是 因为 我 使 用 
了 “智能 协议 ”。 在 网 络 传输 的 两 端 都 局 用 了 相应 的 辅助 程序 ， 实 现 差 异 
传输 及 传输 进度 的 计算 和 显示 。 





Hg: 实际 上 我 也 支持 进度 显示 1| ， 不 过 是 通过 Ptrogress 插 件 站 实现 
的 ， 需 要 通过 修改 配置 文件 启用 该 插件 。 


Hg: 我 有 一 个 特点 是 SVN 用 户 非常 喜欢 的 ， 就 是 我 的 顺序 数字 版 本 
号 。 


Git: 你 的 顺序 数字 版 本 号 只 在 本 地 版 本 库 中 有 效 。 也 就 是 说 ， 你 
不 能 像 SVN 那 样 将 顺序 数字 版 本 号 作为 项 目 本 里 的 版 本 号， 因为 换 成 力 
外 一 个 版 本 库 的 元 隆 ， 那 个 数字 版 本 号 就 会 不 一 样 了。 











Hg: 我 觉得 你 的 暂 存 区 (stage) 的 概念 太古 怪 了 。 我 提交 的 时 候 ， 
改动 的 文件 会 直接 提交 而 不 需要 进行 什么 注册 到 暂 存 区 的 操作 。 

Git: 让 读者 来 做 评判 吧 。 如 果 读 者 读 过 本 书 的 第 2 篇 ， 一 定 会 说 Git 
的 暂 存 区 帅 采 了 。 

Hg: 我 只 允许 用 户 对 最 近 的 一 次 提交 进行 回 滚 撤销 ， 而 你 (Git) 


怎么 能 允许 用 户 撤销 任意 多 次 历史 提交 呢 ? 那样 安全 吗 ? 





Git: 这 就 是 我 的 对 象 库 和 引用 设计 的 强大 之 处 ， 我 可 以 使 用 git 
reset 命 令 将 工作 分 文 进 行 任意 的 重 置 ， 丢 奔 任 意 多 的 历史 。 人 至 于 安全 





性 ， 我 的 重 置 命 令 有 一 个 保险 : reflog， 我 随时 可 以 参照 reflog 的 记录 来 
弥补 错误 的 重 置 。 


Hg: 我 们 的 revert 命 令 好 像 不 同 ? 


Git: 你 Hg 的 hg revert 命 令 和 和 SVN 的 svn revert 命 令 相 似 ， 是 取消 本 地 
修改 ， 用 原始 拷贝 履 新 。 你 的 这 个 操作 在 我 这 里 是 用 git checkout 命 令 来 
实现 的 。 我 也 有 一 个 git revert 命 令 ， 但 是 这 个 命令 是 针对 某 个 历史 提交 


进行 的 反 向 操作 ， 以 取消 该 历史 提交 的 改动 。 


Hg: 我 执行 日 志 查 看 能 够 看 到 文本 显示 的 分 支 图 ， 你 呢 ? 








Git: 我 需要 在 日 志 显 示 时 添加 参数 ， 即 使 用 命令 git log--graph。 我 
文 持 通过 建立 别名 来 实现 简洁 的 调用 ， 例 如 建立 一 个 名 为 glog 的 别名 。 


Git: 我 听 说 你 Hg 不 文 持 分 文 ? 


Hg: 你 说 的 是 昨天 的 我 ， 现 在 有 了 Bookmatks 插 件 | ， 我 也 拥有 和 
你 类 似 的 分 支 实现 。 不 过 传统 来 讲 我 还 是 以 克隆 来 实现 分 支 的 。 


Git: 实际 上 我 的 每 一 个 死 隆 的 版 本 库 也 相当 于 独立 的 分 支 ， 但 是 
因为 我 有 强大 的 分 文 功能 ， 因 此 很 多 用 户 还 没有 意识 到 。 使 用 Topgit 的 
用 户 就 应 该 使 用 版 本 库 殉 隆 作 为 Topgit 本 身 的 分 文 管 理 。 








Git: 还 有 ， 因 为 我 对 分 文 的 完整 文 持 ， 使 得 我 可 以 和 SVN 很 好 地 


协同 工作 。 我 可 以 将 整个 SVN 转 换 为 本 地 的 Git 库 ， 但 是 你 Hg， 


Hg: 是 的 ， 我 要 向 你 多 学 习 。 


[1 感谢 来 自 中 国 台 湾 的 Willie Wu 对 我 博客 的 评论 。 
[2] http:/ /metcutial.selenic.comy/ wiki/ProgressExtension 


[3] http:/ /metcutial.selenic.comy/ wiki/BookmarksExtension 


D.2 Git 和 Hg 命令 对 照 


比较 项 目 HG 命令 GIT 命令 
git://host/path/to/repos.git 
ssh://user(@host/path/to/repos ssh://user(@host/path/to/repos.git 
URL file:///path/to/repos user(@host:path/to/repos.git 


/path/to/repos file:///path/to/repos.git 


[ul [user] 
配置 username = Firsthname Lastname <maill(@ name = Firstname Lastname 
add1> emall = mail(Qaddr 





比较 项 目 
版 本 库 初 始 化 
版 本 库 克隆 
获取 版 本 库 更 新 
更 新 至 历史 版 本 
更 新 到 指定 日 其 
更 新 至 最 新 提交 
切换 至 里 程 碑 
切换 至 分 支 


还 原文 件 / 强制 蓝 盖 


添加 文件 
删除 文件 
添加 及 删除 文件 
移动 文件 


撤销 添加 、 删 除 等 操作 


清除 未 跟踪 文件 
获取 文件 历史 版 本 
反 删 除 文件 


工作 区 差异 比较 


版 本 间 差 异 比 较 
查看 工作 区 状态 
提交 


推送 提交 


显示 提交 日 志 


逐 行 追 洲 


显示 里 程 碑 /分 支 


( 续 ) 


HG 命令 GIT 命令 


hg init <path> git init [--bare] <path> 
hg clone <url> <path> git clone <url> <path> 
hg pull --update git pull 
hg update -r <rev> git checkout <commit> 
hg update -d <date> git checkout HEAD@'{<date>》 
hg update git checkout master 
hg update -r <tag> git checkout <tag> 
hg update -r <branch> git checkout <branch> 
hg update -C <path> git checkout -- <path> 
hg add <path> git add <path> 
hg rm <path> git rm <path> 
hg addremove gitadd -A 
hg mv <old> <new> git mv <old> <new> 
hg revert <path> git reset -- <path> 
git clean -fd 

hg cat -r<rev> <path> > <output> git show <commit>:<path> > <output> 
hg add <path> git add <path> 
git diff 

hg diff git diff --cached 


git diff HEAD 


hg diff -r <rev1l> -r <rev2> <path> git diff <commitl> <commit2> -- <path> 


hg status git status -S 
hg commit -m "<msg>" git commit -a -m "<msg>" 
git push 

hg log | less git log 

hg glog | less git log --graph 
hg annotate git annotate, git blame 
hg tags git tag 


hg branches 


hg bookmarks Sedmanen 


hg heads git show-ref 


比较 项 目 
创建 里 程 碑 
删除 里 程 碑 


创建 分 支 


删除 分 支 


导出 项 目 文件 


反 转 提交 
提交 拣选 
分 支 合并 
变 基 


冲突 解决 


更 改 提交 说 明 
撤销 最 后 一 次 提交 
撤销 多 次 提交 
撤销 历史 提交 
启动 Web 浏览 
二 分 查找 

内 容 搜索 

提交 导出 补丁 文件 
工作 区 根 目录 


杂项 


HG 命令 


hg tag [-m "<msg>"] [-r <rev>] <tagname> 


hg tag --remove <tagname> git tag -d <tagname> 


hg branch <branch> 


hg bookmark <branch> 





hg commit --close-branch 
hg bookmark -d <branch> 


hg archive -r <rev> <output.tar.gZ> 





( 续 ) 
GIT 命令 


git tag [-m "<mse>"] <tagname> [<commit>] 


git branch <branch> <commit> 


git checkout -b <branch> <commit> 
git branch -d <branch> 


git archive -0o <output.tar> <commit> 


git archive -0 <output.tar> --remote=<url> 
<commit> 


etreset (sof | hard ] HEAD 

git reset [ --soft | --hard ] HEAD~<n> 
git rebase -i <commit> 人 ^ 

eit grep 

git rev-parse --show-toplevel 


